draft-ietf-netmod-yang-01.txt   draft-ietf-netmod-yang-02.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 August 29, 2008 Intended status: Standards Track November 3, 2008
Expires: March 2, 2009 Expires: May 7, 2009
YANG - A data modeling language for NETCONF YANG - A data modeling language for NETCONF
draft-ietf-netmod-yang-01 draft-ietf-netmod-yang-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 2, 2009. This Internet-Draft will expire on May 7, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
YANG is a data modeling language used to model configuration and YANG is a data modeling language used to model configuration and
state data manipulated by the NETCONF protocol, NETCONF remote state data manipulated by the NETCONF protocol, NETCONF remote
procedure calls, and NETCONF notifications. procedure calls, and NETCONF notifications.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Mandatory nodes . . . . . . . . . . . . . . . . . . . . . 11 3.1. Mandatory nodes . . . . . . . . . . . . . . . . . . . . . 12
4. YANG Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 4. YANG Overview . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Functional Overview . . . . . . . . . . . . . . . . . . . 12 4.1. Functional Overview . . . . . . . . . . . . . . . . . . . 13
4.2. Language Overview . . . . . . . . . . . . . . . . . . . . 13 4.2. Language Overview . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Modules and Submodules . . . . . . . . . . . . . . . 13 4.2.1. Modules and Submodules . . . . . . . . . . . . . . . 14
4.2.2. Data Modeling Basics . . . . . . . . . . . . . . . . 14 4.2.2. Data Modeling Basics . . . . . . . . . . . . . . . . 15
4.2.3. Operational Data . . . . . . . . . . . . . . . . . . 19 4.2.3. Operational Data . . . . . . . . . . . . . . . . . . 20
4.2.4. Built-in Types . . . . . . . . . . . . . . . . . . . 19 4.2.4. Built-in Types . . . . . . . . . . . . . . . . . . . 20
4.2.5. Derived Types (typedef) . . . . . . . . . . . . . . . 20 4.2.5. Derived Types (typedef) . . . . . . . . . . . . . . . 21
4.2.6. Reusable Node Groups (grouping) . . . . . . . . . . . 21 4.2.6. Reusable Node Groups (grouping) . . . . . . . . . . . 22
4.2.7. Choices . . . . . . . . . . . . . . . . . . . . . . . 22 4.2.7. Choices . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.8. Extending Data Models (augment) . . . . . . . . . . . 23 4.2.8. Extending Data Models (augment) . . . . . . . . . . . 24
4.2.9. RPC Definitions . . . . . . . . . . . . . . . . . . . 24 4.2.9. RPC Definitions . . . . . . . . . . . . . . . . . . . 25
4.2.10. Notification Definitions . . . . . . . . . . . . . . 25 4.2.10. Notification Definitions . . . . . . . . . . . . . . 26
5. Language Concepts . . . . . . . . . . . . . . . . . . . . . . 27 5. Language Concepts . . . . . . . . . . . . . . . . . . . . . . 28
5.1. Modules and Submodules . . . . . . . . . . . . . . . . . 27 5.1. Modules and Submodules . . . . . . . . . . . . . . . . . 28
5.1.1. Module Hierarchies . . . . . . . . . . . . . . . . . 27 5.1.1. Module Hierarchies . . . . . . . . . . . . . . . . . 28
5.2. File Layout . . . . . . . . . . . . . . . . . . . . . . . 27 5.2. File Layout . . . . . . . . . . . . . . . . . . . . . . . 28
5.3. Object Based View of YANG . . . . . . . . . . . . . . . . 28 5.3. Object Based View of YANG . . . . . . . . . . . . . . . . 29
5.4. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 28 5.4. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 29
5.4.1. YANG Namespace . . . . . . . . . . . . . . . . . . . 29 5.4.1. YANG Namespace . . . . . . . . . . . . . . . . . . . 30
5.5. Ordering . . . . . . . . . . . . . . . . . . . . . . . . 29 5.5. Ordering . . . . . . . . . . . . . . . . . . . . . . . . 30
5.6. Containers with Presence . . . . . . . . . . . . . . . . 30 5.6. Containers with Presence . . . . . . . . . . . . . . . . 31
5.7. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.7. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.8. Nested Typedefs and Groupings . . . . . . . . . . . . . . 31 5.8. Nested Typedefs and Groupings . . . . . . . . . . . . . . 32
6. YANG syntax . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.9. Conformance . . . . . . . . . . . . . . . . . . . . . . . 32
6.1. Lexicographical Tokenization . . . . . . . . . . . . . . 32 5.9.1. Basic Behavior . . . . . . . . . . . . . . . . . . . 33
6.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 32 5.9.2. Optional Features . . . . . . . . . . . . . . . . . . 33
6.1.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 32 5.9.3. Deviations . . . . . . . . . . . . . . . . . . . . . 34
6.1.3. Quoting . . . . . . . . . . . . . . . . . . . . . . . 32 5.9.4. Announcing Conformance Information in the <hello>
6.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 34 Message . . . . . . . . . . . . . . . . . . . . . . . 34
6.2.1. Identifiers and their namespaces . . . . . . . . . . 34 6. YANG syntax . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.3. Statements . . . . . . . . . . . . . . . . . . . . . . . 34 6.1. Lexicographical Tokenization . . . . . . . . . . . . . . 36
6.3.1. Language Extensions . . . . . . . . . . . . . . . . . 35 6.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 36
6.4. XPath Evaluations . . . . . . . . . . . . . . . . . . . . 35 6.1.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 36
7. YANG Statements . . . . . . . . . . . . . . . . . . . . . . . 36 6.1.3. Quoting . . . . . . . . . . . . . . . . . . . . . . . 36
7.1. The module Statement . . . . . . . . . . . . . . . . . . 36 6.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 38
7.1.1. The module's Substatements . . . . . . . . . . . . . 37 6.2.1. Identifiers and their namespaces . . . . . . . . . . 38
7.1.2. The yang-version Statement . . . . . . . . . . . . . 38 6.3. Statements . . . . . . . . . . . . . . . . . . . . . . . 39
7.1.3. The namespace Statement . . . . . . . . . . . . . . . 38 6.3.1. Language Extensions . . . . . . . . . . . . . . . . . 39
7.1.4. The prefix Statement . . . . . . . . . . . . . . . . 39 6.4. XPath Evaluations . . . . . . . . . . . . . . . . . . . . 39
7.1.5. The import Statement . . . . . . . . . . . . . . . . 39 7. YANG Statements . . . . . . . . . . . . . . . . . . . . . . . 40
7.1.6. The include Statement . . . . . . . . . . . . . . . . 40 7.1. The module Statement . . . . . . . . . . . . . . . . . . 40
7.1.7. The organization Statement . . . . . . . . . . . . . 40 7.1.1. The module's Substatements . . . . . . . . . . . . . 41
7.1.8. The contact Statement . . . . . . . . . . . . . . . . 40 7.1.2. The yang-version Statement . . . . . . . . . . . . . 42
7.1.9. The revision Statement . . . . . . . . . . . . . . . 40 7.1.3. The namespace Statement . . . . . . . . . . . . . . . 43
7.1.10. Usage Example . . . . . . . . . . . . . . . . . . . . 41 7.1.4. The prefix Statement . . . . . . . . . . . . . . . . 43
7.2. The submodule Statement . . . . . . . . . . . . . . . . . 41 7.1.5. The import Statement . . . . . . . . . . . . . . . . 43
7.2.1. The submodule's Substatements . . . . . . . . . . . . 43 7.1.6. The include Statement . . . . . . . . . . . . . . . . 44
7.2.2. The belongs-to Statement . . . . . . . . . . . . . . 44 7.1.7. The organization Statement . . . . . . . . . . . . . 44
7.2.3. Usage Example . . . . . . . . . . . . . . . . . . . . 45 7.1.8. The contact Statement . . . . . . . . . . . . . . . . 44
7.3. The typedef Statement . . . . . . . . . . . . . . . . . . 45 7.1.9. The revision Statement . . . . . . . . . . . . . . . 44
7.3.1. The typedef's Substatements . . . . . . . . . . . . . 46 7.1.10. Usage Example . . . . . . . . . . . . . . . . . . . . 45
7.3.2. The typedef's type Statement . . . . . . . . . . . . 46 7.2. The submodule Statement . . . . . . . . . . . . . . . . . 45
7.3.3. The units Statement . . . . . . . . . . . . . . . . . 46 7.2.1. The submodule's Substatements . . . . . . . . . . . . 47
7.3.4. The typedef's default Statement . . . . . . . . . . . 46 7.2.2. The belongs-to Statement . . . . . . . . . . . . . . 48
7.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 47 7.2.3. Usage Example . . . . . . . . . . . . . . . . . . . . 49
7.4. The type Statement . . . . . . . . . . . . . . . . . . . 47 7.3. The typedef Statement . . . . . . . . . . . . . . . . . . 49
7.4.1. The type's Substatements . . . . . . . . . . . . . . 47 7.3.1. The typedef's Substatements . . . . . . . . . . . . . 50
7.5. The container Statement . . . . . . . . . . . . . . . . . 47 7.3.2. The typedef's type Statement . . . . . . . . . . . . 50
7.5.1. The container's Substatements . . . . . . . . . . . . 48 7.3.3. The units Statement . . . . . . . . . . . . . . . . . 50
7.5.2. The must Statement . . . . . . . . . . . . . . . . . 48 7.3.4. The typedef's default Statement . . . . . . . . . . . 50
7.5.3. The must's Substatements . . . . . . . . . . . . . . 49 7.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 51
7.5.4. The presence Statement . . . . . . . . . . . . . . . 50 7.4. The type Statement . . . . . . . . . . . . . . . . . . . 51
7.5.5. The container's Child Node Statements . . . . . . . . 50 7.4.1. The type's Substatements . . . . . . . . . . . . . . 51
7.5.6. XML Encoding Rules . . . . . . . . . . . . . . . . . 50 7.5. The container Statement . . . . . . . . . . . . . . . . . 51
7.5.7. NETCONF <edit-config> Operations . . . . . . . . . . 51 7.5.1. The container's Substatements . . . . . . . . . . . . 52
7.5.8. Usage Example . . . . . . . . . . . . . . . . . . . . 51 7.5.2. The must Statement . . . . . . . . . . . . . . . . . 52
7.6. The leaf Statement . . . . . . . . . . . . . . . . . . . 52 7.5.3. The must's Substatements . . . . . . . . . . . . . . 53
7.6.1. The leaf's Substatements . . . . . . . . . . . . . . 53 7.5.4. The presence Statement . . . . . . . . . . . . . . . 54
7.6.2. The leaf's type Statement . . . . . . . . . . . . . . 53 7.5.5. The container's Child Node Statements . . . . . . . . 55
7.6.3. The leaf's default Statement . . . . . . . . . . . . 53 7.5.6. XML Encoding Rules . . . . . . . . . . . . . . . . . 55
7.6.4. The leaf's mandatory Statement . . . . . . . . . . . 53 7.5.7. NETCONF <edit-config> Operations . . . . . . . . . . 55
7.6.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 54 7.5.8. Usage Example . . . . . . . . . . . . . . . . . . . . 56
7.6.6. NETCONF <edit-config> Operations . . . . . . . . . . 54 7.6. The leaf Statement . . . . . . . . . . . . . . . . . . . 57
7.6.7. Usage Example . . . . . . . . . . . . . . . . . . . . 54 7.6.1. The leaf's Substatements . . . . . . . . . . . . . . 58
7.7. The leaf-list Statement . . . . . . . . . . . . . . . . . 55 7.6.2. The leaf's type Statement . . . . . . . . . . . . . . 58
7.7.1. The leaf-list's Substatements . . . . . . . . . . . . 56 7.6.3. The leaf's default Statement . . . . . . . . . . . . 58
7.7.2. The min-elements Statement . . . . . . . . . . . . . 56 7.6.4. The leaf's mandatory Statement . . . . . . . . . . . 58
7.7.3. The max-elements Statement . . . . . . . . . . . . . 56 7.6.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 59
7.7.4. The ordered-by Statement . . . . . . . . . . . . . . 56 7.6.6. NETCONF <edit-config> Operations . . . . . . . . . . 59
7.7.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 57 7.6.7. Usage Example . . . . . . . . . . . . . . . . . . . . 59
7.7.6. NETCONF <edit-config> operations . . . . . . . . . . 57 7.7. The leaf-list Statement . . . . . . . . . . . . . . . . . 60
7.7.7. Usage Example . . . . . . . . . . . . . . . . . . . . 58 7.7.1. The leaf-list's Substatements . . . . . . . . . . . . 61
7.8. The list Statement . . . . . . . . . . . . . . . . . . . 59 7.7.2. The min-elements Statement . . . . . . . . . . . . . 61
7.8.1. The list's Substatements . . . . . . . . . . . . . . 60 7.7.3. The max-elements Statement . . . . . . . . . . . . . 61
7.8.2. The list's key Statement . . . . . . . . . . . . . . 60 7.7.4. The ordered-by Statement . . . . . . . . . . . . . . 61
7.8.3. The lists's unique Statement . . . . . . . . . . . . 61 7.7.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 62
7.8.4. The list's Child Node Statements . . . . . . . . . . 62 7.7.6. NETCONF <edit-config> operations . . . . . . . . . . 62
7.8.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 62 7.7.7. Usage Example . . . . . . . . . . . . . . . . . . . . 63
7.8.6. NETCONF <edit-config> operations . . . . . . . . . . 62 7.8. The list Statement . . . . . . . . . . . . . . . . . . . 65
7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 63 7.8.1. The list's Substatements . . . . . . . . . . . . . . 65
7.9. The choice Statement . . . . . . . . . . . . . . . . . . 66 7.8.2. The list's key Statement . . . . . . . . . . . . . . 66
7.9.1. The choice's Substatements . . . . . . . . . . . . . 66 7.8.3. The lists's unique Statement . . . . . . . . . . . . 67
7.9.2. The choice's case Statement . . . . . . . . . . . . . 66 7.8.4. The list's Child Node Statements . . . . . . . . . . 68
7.9.3. The choice's default Statement . . . . . . . . . . . 68 7.8.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 68
7.9.4. The choice's mandatory Statement . . . . . . . . . . 69 7.8.6. NETCONF <edit-config> operations . . . . . . . . . . 68
7.9.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 69 7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 69
7.9.6. NETCONF <edit-config> operations . . . . . . . . . . 69 7.9. The choice Statement . . . . . . . . . . . . . . . . . . 72
7.9.7. Usage Example . . . . . . . . . . . . . . . . . . . . 70 7.9.1. The choice's Substatements . . . . . . . . . . . . . 73
7.10. The anyxml Statement . . . . . . . . . . . . . . . . . . 71 7.9.2. The choice's case Statement . . . . . . . . . . . . . 73
7.10.1. The anyxml's Substatements . . . . . . . . . . . . . 71 7.9.3. The choice's default Statement . . . . . . . . . . . 74
7.10.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 71 7.9.4. The choice's mandatory Statement . . . . . . . . . . 76
7.10.3. NETCONF <edit-config> operations . . . . . . . . . . 71 7.9.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 76
7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . . 72 7.9.6. NETCONF <edit-config> operations . . . . . . . . . . 76
7.11. The grouping Statement . . . . . . . . . . . . . . . . . 72 7.9.7. Usage Example . . . . . . . . . . . . . . . . . . . . 76
7.11.1. The grouping's Substatements . . . . . . . . . . . . 74 7.10. The anyxml Statement . . . . . . . . . . . . . . . . . . 77
7.11.2. Usage Example . . . . . . . . . . . . . . . . . . . . 74 7.10.1. The anyxml's Substatements . . . . . . . . . . . . . 78
7.12. The uses Statement . . . . . . . . . . . . . . . . . . . 74 7.10.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 78
7.12.1. The uses's Substatements . . . . . . . . . . . . . . 75 7.10.3. NETCONF <edit-config> operations . . . . . . . . . . 78
7.12.2. The uses's Refinement Statements . . . . . . . . . . 75 7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . . 79
7.12.3. XML Encoding Rules . . . . . . . . . . . . . . . . . 76 7.11. The grouping Statement . . . . . . . . . . . . . . . . . 79
7.12.4. Usage Example . . . . . . . . . . . . . . . . . . . . 76 7.11.1. The grouping's Substatements . . . . . . . . . . . . 80
7.13. The rpc Statement . . . . . . . . . . . . . . . . . . . . 77 7.11.2. Usage Example . . . . . . . . . . . . . . . . . . . . 80
7.13.1. The rpc's Substatements . . . . . . . . . . . . . . . 78 7.12. The uses Statement . . . . . . . . . . . . . . . . . . . 80
7.13.2. The input Statement . . . . . . . . . . . . . . . . . 78 7.12.1. The uses's Substatements . . . . . . . . . . . . . . 81
7.13.3. The output Statement . . . . . . . . . . . . . . . . 79 7.12.2. The refine Statement . . . . . . . . . . . . . . . . 81
7.13.4. XML Encoding Rules . . . . . . . . . . . . . . . . . 80 7.12.3. XML Encoding Rules . . . . . . . . . . . . . . . . . 82
7.13.5. Usage Example . . . . . . . . . . . . . . . . . . . . 80 7.12.4. Usage Example . . . . . . . . . . . . . . . . . . . . 82
7.14. The notification Statement . . . . . . . . . . . . . . . 81 7.13. The rpc Statement . . . . . . . . . . . . . . . . . . . . 83
7.14.1. The notification's Substatements . . . . . . . . . . 82 7.13.1. The rpc's Substatements . . . . . . . . . . . . . . . 84
7.14.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 82 7.13.2. The input Statement . . . . . . . . . . . . . . . . . 84
7.14.3. Usage Example . . . . . . . . . . . . . . . . . . . . 82 7.13.3. The output Statement . . . . . . . . . . . . . . . . 85
7.15. The augment Statement . . . . . . . . . . . . . . . . . . 83 7.13.4. XML Encoding Rules . . . . . . . . . . . . . . . . . 86
7.15.1. The augment's Substatements . . . . . . . . . . . . . 84 7.13.5. Usage Example . . . . . . . . . . . . . . . . . . . . 86
7.15.2. The when Statement . . . . . . . . . . . . . . . . . 84 7.14. The notification Statement . . . . . . . . . . . . . . . 87
7.15.3. XML Encoding Rules . . . . . . . . . . . . . . . . . 85 7.14.1. The notification's Substatements . . . . . . . . . . 88
7.15.4. Usage Example . . . . . . . . . . . . . . . . . . . . 85 7.14.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 88
7.16. The extension Statement . . . . . . . . . . . . . . . . . 87 7.14.3. Usage Example . . . . . . . . . . . . . . . . . . . . 88
7.16.1. The extension's Substatements . . . . . . . . . . . . 88 7.15. The augment Statement . . . . . . . . . . . . . . . . . . 89
7.16.2. The argument Statement . . . . . . . . . . . . . . . 88 7.15.1. The augment's Substatements . . . . . . . . . . . . . 90
7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . . 88 7.15.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 90
7.17. Common Statements . . . . . . . . . . . . . . . . . . . . 89 7.15.3. Usage Example . . . . . . . . . . . . . . . . . . . . 91
7.17.1. The config Statement . . . . . . . . . . . . . . . . 89 7.16. The identity Statement . . . . . . . . . . . . . . . . . 93
7.17.2. The status Statement . . . . . . . . . . . . . . . . 90 7.16.1. The identity's Substatements . . . . . . . . . . . . 93
7.17.3. The description Statement . . . . . . . . . . . . . . 90 7.16.2. The base Statement . . . . . . . . . . . . . . . . . 93
7.17.4. The reference Statement . . . . . . . . . . . . . . . 90 7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . . 94
8. Built-in Types . . . . . . . . . . . . . . . . . . . . . . . 91 7.17. The extension Statement . . . . . . . . . . . . . . . . . 94
8.1. The Integer Built-in Types . . . . . . . . . . . . . . . 91 7.17.1. The extension's Substatements . . . . . . . . . . . . 95
8.1.1. Lexicographic Representation . . . . . . . . . . . . 92 7.17.2. The argument Statement . . . . . . . . . . . . . . . 95
8.1.2. Restrictions . . . . . . . . . . . . . . . . . . . . 92 7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . . 96
8.1.3. The range Statement . . . . . . . . . . . . . . . . . 92 7.18. Conformance-related Statements . . . . . . . . . . . . . 96
8.1.4. Usage Example . . . . . . . . . . . . . . . . . . . . 93 7.18.1. The feature Statement . . . . . . . . . . . . . . . . 96
8.2. The Floating Point Built-in Types . . . . . . . . . . . . 93 7.18.2. The if-feature Statement . . . . . . . . . . . . . . 98
8.2.1. Lexicographic Representation . . . . . . . . . . . . 94 7.18.3. The deviation Statement . . . . . . . . . . . . . . . 98
8.2.2. Restrictions . . . . . . . . . . . . . . . . . . . . 94 7.19. Common Statements . . . . . . . . . . . . . . . . . . . . 101
8.2.3. Usage Example . . . . . . . . . . . . . . . . . . . . 94 7.19.1. The config Statement . . . . . . . . . . . . . . . . 101
8.3. The string Built-in Type . . . . . . . . . . . . . . . . 94 7.19.2. The status Statement . . . . . . . . . . . . . . . . 101
8.3.1. Lexicographic Representation . . . . . . . . . . . . 94 7.19.3. The description Statement . . . . . . . . . . . . . . 102
8.3.2. Restrictions . . . . . . . . . . . . . . . . . . . . 94 7.19.4. The reference Statement . . . . . . . . . . . . . . . 102
8.3.3. The length Statement . . . . . . . . . . . . . . . . 95 7.19.5. The when Statement . . . . . . . . . . . . . . . . . 102
8.3.4. Usage Example . . . . . . . . . . . . . . . . . . . . 96 8. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 104
8.3.5. The pattern Statement . . . . . . . . . . . . . . . . 96 9. Built-in Types . . . . . . . . . . . . . . . . . . . . . . . 105
8.3.6. Usage Example . . . . . . . . . . . . . . . . . . . . 96 9.1. Canonical representation . . . . . . . . . . . . . . . . 105
8.4. The boolean Built-in Type . . . . . . . . . . . . . . . . 97 9.2. The Integer Built-in Types . . . . . . . . . . . . . . . 105
8.4.1. Lexicographic Representation . . . . . . . . . . . . 97 9.2.1. Lexicographic Representation . . . . . . . . . . . . 106
8.4.2. Restrictions . . . . . . . . . . . . . . . . . . . . 97 9.2.2. Canonical Form . . . . . . . . . . . . . . . . . . . 106
8.5. The enumeration Built-in Type . . . . . . . . . . . . . . 97 9.2.3. Restrictions . . . . . . . . . . . . . . . . . . . . 106
8.5.1. Lexicographic Representation . . . . . . . . . . . . 97 9.2.4. The range Statement . . . . . . . . . . . . . . . . . 107
8.5.2. Restrictions . . . . . . . . . . . . . . . . . . . . 97 9.2.5. Usage Example . . . . . . . . . . . . . . . . . . . . 108
8.5.3. The enum Statement . . . . . . . . . . . . . . . . . 97 9.3. The Floating Point Built-in Types . . . . . . . . . . . . 108
8.5.4. Usage Example . . . . . . . . . . . . . . . . . . . . 98 9.3.1. Lexicographic Representation . . . . . . . . . . . . 108
8.6. The bits Built-in Type . . . . . . . . . . . . . . . . . 99 9.3.2. Canonical Form . . . . . . . . . . . . . . . . . . . 108
8.6.1. Restrictions . . . . . . . . . . . . . . . . . . . . 99 9.3.3. Restrictions . . . . . . . . . . . . . . . . . . . . 108
8.6.2. Lexicographic Representation . . . . . . . . . . . . 99 9.3.4. Usage Example . . . . . . . . . . . . . . . . . . . . 109
8.6.3. The bit Statement . . . . . . . . . . . . . . . . . . 99 9.4. The string Built-in Type . . . . . . . . . . . . . . . . 109
8.6.4. Usage Example . . . . . . . . . . . . . . . . . . . . 100 9.4.1. Lexicographic Representation . . . . . . . . . . . . 109
8.7. The binary Built-in Type . . . . . . . . . . . . . . . . 100 9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 109
8.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 100 9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 109
8.7.2. Lexicographic Representation . . . . . . . . . . . . 100 9.4.4. The length Statement . . . . . . . . . . . . . . . . 109
8.8. The keyref Built-in Type . . . . . . . . . . . . . . . . 101 9.4.5. Usage Example . . . . . . . . . . . . . . . . . . . . 110
8.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 101 9.4.6. The pattern Statement . . . . . . . . . . . . . . . . 111
8.8.2. The path Statement . . . . . . . . . . . . . . . . . 101 9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 111
8.8.3. Lexicographic Representation . . . . . . . . . . . . 101 9.5. The boolean Built-in Type . . . . . . . . . . . . . . . . 111
8.8.4. Usage Example . . . . . . . . . . . . . . . . . . . . 101 9.5.1. Lexicographic Representation . . . . . . . . . . . . 112
8.9. The empty Built-in Type . . . . . . . . . . . . . . . . . 103 9.5.2. Restrictions . . . . . . . . . . . . . . . . . . . . 112
8.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 103 9.6. The enumeration Built-in Type . . . . . . . . . . . . . . 112
8.9.2. Lexicographic Representation . . . . . . . . . . . . 103 9.6.1. Lexicographic Representation . . . . . . . . . . . . 112
8.9.3. Usage Example . . . . . . . . . . . . . . . . . . . . 103 9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 112
8.10. The union Built-in Type . . . . . . . . . . . . . . . . . 104 9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 112
8.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 104 9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 112
8.10.2. Lexicographic Representation . . . . . . . . . . . . 104 9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 113
8.11. The instance-identifier Built-in Type . . . . . . . . . . 104 9.7. The bits Built-in Type . . . . . . . . . . . . . . . . . 114
8.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 105 9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 114
8.11.2. Lexicographic Representation . . . . . . . . . . . . 105 9.7.2. Lexicographic Representation . . . . . . . . . . . . 114
8.11.3. Usage Example . . . . . . . . . . . . . . . . . . . . 105 9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 114
9. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 106 9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 114
10. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 115
10.1. Formal YIN Definition . . . . . . . . . . . . . . . . . . 107 9.8. The binary Built-in Type . . . . . . . . . . . . . . . . 115
10.2. Transformation Algorithm YANG-2-YIN . . . . . . . . . . . 107 9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 116
10.2.1. Usage Example . . . . . . . . . . . . . . . . . . . . 109 9.8.2. Lexicographic Representation . . . . . . . . . . . . 116
10.3. Transformation Algorithm YIN-2-YANG . . . . . . . . . . . 109 9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 116
10.3.1. Tabulation, Formatting . . . . . . . . . . . . . . . 110 9.9. The keyref Built-in Type . . . . . . . . . . . . . . . . 116
11. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 111 9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 116
12. Error Responses for YANG Related Errors . . . . . . . . . . . 130 9.9.2. The path Statement . . . . . . . . . . . . . . . . . 116
12.1. Error Message for Data that Violates a YANG unique 9.9.3. Lexicographic Representation . . . . . . . . . . . . 117
Statement: . . . . . . . . . . . . . . . . . . . . . . . 130 9.9.4. Canonical Form . . . . . . . . . . . . . . . . . . . 117
12.2. Error Message for Data that Violates a YANG 9.9.5. Usage Example . . . . . . . . . . . . . . . . . . . . 117
max-elements Statement: . . . . . . . . . . . . . . . . . 130 9.10. The identityref Built-in Type . . . . . . . . . . . . . . 118
12.3. Error Message for Data that Violates a YANG 9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 118
min-elements Statement: . . . . . . . . . . . . . . . . . 130 9.10.2. The identityref's base Statement . . . . . . . . . . 119
12.4. Error Message for Data that Violates a YANG must 9.10.3. Lexicographic Representation . . . . . . . . . . . . 119
statement: . . . . . . . . . . . . . . . . . . . . . . . 131 9.10.4. Usage Example . . . . . . . . . . . . . . . . . . . . 119
12.5. Error Message for the "insert" Operation . . . . . . . . 131 9.11. The empty Built-in Type . . . . . . . . . . . . . . . . . 120
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 132 9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 120
14. Security Considerations . . . . . . . . . . . . . . . . . . . 133 9.11.2. Lexicographic Representation . . . . . . . . . . . . 120
15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 134 9.11.3. Canonical Representation . . . . . . . . . . . . . . 120
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 135 9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . . 120
16.1. Normative References . . . . . . . . . . . . . . . . . . 135 9.12. The union Built-in Type . . . . . . . . . . . . . . . . . 120
16.2. Non-Normative References . . . . . . . . . . . . . . . . 136 9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 121
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 137 9.12.2. Lexicographic Representation . . . . . . . . . . . . 121
A.1. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 137 9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 121
A.2. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 138 9.13. The instance-identifier Built-in Type . . . . . . . . . . 121
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 139 9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 121
Intellectual Property and Copyright Statements . . . . . . . . . 140 9.13.2. Lexicographic Representation . . . . . . . . . . . . 121
9.13.3. Canonical Form . . . . . . . . . . . . . . . . . . . 122
9.13.4. Usage Example . . . . . . . . . . . . . . . . . . . . 122
10. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 123
11. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
11.1. Formal YIN Definition . . . . . . . . . . . . . . . . . . 126
11.2. Transformation Algorithm YANG-2-YIN . . . . . . . . . . . 126
11.2.1. Usage Example . . . . . . . . . . . . . . . . . . . . 128
11.3. Transformation Algorithm YIN-2-YANG . . . . . . . . . . . 129
11.3.1. Tabulation, Formatting . . . . . . . . . . . . . . . 129
12. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 130
13. Error Responses for YANG Related Errors . . . . . . . . . . . 151
13.1. Error Message for Data that Violates a YANG unique
Statement: . . . . . . . . . . . . . . . . . . . . . . . 151
13.2. Error Message for Data that Violates a YANG
max-elements Statement: . . . . . . . . . . . . . . . . . 151
13.3. Error Message for Data that Violates a YANG
min-elements Statement: . . . . . . . . . . . . . . . . . 151
13.4. Error Message for Data that Violates a YANG must
statement: . . . . . . . . . . . . . . . . . . . . . . . 152
13.5. Error Message for the "insert" Operation . . . . . . . . 152
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 153
15. Security Considerations . . . . . . . . . . . . . . . . . . . 154
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 155
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 156
17.1. Normative References . . . . . . . . . . . . . . . . . . 156
17.2. Non-Normative References . . . . . . . . . . . . . . . . 157
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 158
A.1. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 158
A.2. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 158
A.3. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 159
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 160
Intellectual Property and Copyright Statements . . . . . . . . . 161
1. Introduction 1. Introduction
Today, the NETCONF protocol [RFC4741] lacks a standardized way to Today, the NETCONF protocol [RFC4741] lacks a standardized way to
create data models. Instead, vendors are forced to use proprietary create data models. Instead, vendors are forced to use proprietary
solutions. In order for NETCONF to be a interoperable protocol, solutions. In order for NETCONF to be a interoperable protocol,
models must be defined in a vendor-neutral way. YANG provides the models must be defined in a vendor-neutral way. YANG provides the
language and rules for defining such models for use with NETCONF. language and rules for defining such models for use with NETCONF.
YANG is a data modeling language used to model configuration and YANG is a data modeling language used to model configuration and
skipping to change at page 9, line 24 skipping to change at page 10, line 24
o built-in type: A YANG data type defined in the YANG language, such o built-in type: A YANG data type defined in the YANG language, such
as uint32 or string. as uint32 or string.
o choice: A node where only one of a number of identified o choice: A node where only one of a number of identified
alternative values is valid. alternative values is valid.
o configuration data: The set of writable data that is required to o configuration data: The set of writable data that is required to
transform a system from its initial default state into its current transform a system from its initial default state into its current
state [RFC4741]. state [RFC4741].
o conformance: A measure of how accurately a device follows the
model.
o container: An interior node in the data tree which exist in at o container: An interior node in the data tree which exist in at
most one instance. A container node has no value, but rather a most one instance. A container node has no value, but rather a
set of child nodes. set of child nodes.
o data definition statement: A statement that defines new data o data definition statement: A statement that defines new data
nodes. One of container, leaf, leaf-list, list, augment, uses, nodes. One of container, leaf, leaf-list, list, choice, case,
and anyxml. augment, uses, and anyxml.
o data model: A data model describes how data is represented and o data model: A data model describes how data is represented and
accessed. accessed.
o data model object: A definition within a module that represents a o data model object: A definition within a module that represents a
construct which can be accessed via a network management protocol. construct which can be accessed via a network management protocol.
Also called an object. Also called an object.
o data node: A node in the schema tree that can be instantiated in a o data node: A node in the schema tree that can be instantiated in a
data tree. One of container, leaf, leaf-list, list, and anyxml. data tree. One of container, leaf, leaf-list, list, and anyxml.
o data tree: The instantiated tree of configuration and state data o data tree: The instantiated tree of configuration and state data
on a device. on a device.
o derived type: A type which is derived from a built-in type (such o derived type: A type which is derived from a built-in type (such
as uint32), or another derived type. as uint32), or another derived type.
o device deviation: A failure of the device to implement the module
faithfully.
o extension: An extension attaches non-YANG semantics to nodes. The o extension: An extension attaches non-YANG semantics to nodes. The
extension statement defines new statements to express these extension statement defines new statements to express these
semantics. semantics.
o feature: A mechanism for marking a portion of the model as
optional. Definitions can be tagged with a feature name and are
only valid on devices which support that feature.
o grouping: A reusable set of nodes, which may be used locally in o grouping: A reusable set of nodes, which may be used locally in
the module, in modules which include it, and by other modules the module, in modules which include it, and by other modules
which import from it. which import from it.
o identifier: Used to identify different kinds of YANG items by o identifier: Used to identify different kinds of YANG items by
name. name.
o instance identifier: A mechanism for identifying a particular node o instance identifier: A mechanism for identifying a particular node
in a data tree. in a data tree.
skipping to change at page 10, line 41 skipping to change at page 11, line 49
used for NETCONF-based operations. With its definitions and the used for NETCONF-based operations. With its definitions and the
definitions it imports or includes from elsewhere, a module is definitions it imports or includes from elsewhere, a module is
self-contained and "compilable". self-contained and "compilable".
o RPC: A Remote Procedure Call, as used within the NETCONF protocol. o RPC: A Remote Procedure Call, as used within the NETCONF protocol.
o RPC method: A specific Remote Procedure Call, as used within the o RPC method: A specific Remote Procedure Call, as used within the
NETCONF protocol. Also called a protocol operation. NETCONF protocol. Also called a protocol operation.
o schema node: A node in the schema tree. One of container, leaf, o schema node: A node in the schema tree. One of container, leaf,
leaf-list, list, choice, case, rpc, input, output, and leaf-list, list, choice, case, rpc, input, output, notification,
notification. and anyxml.
o schema node identifier: A mechanism for identifying a particular o schema node identifier: A mechanism for identifying a particular
node in the schema tree. node in the schema tree.
o schema tree: The definition hierarchy specified within a module. o schema tree: The definition hierarchy specified within a module.
o state data: The additional data on a system that is not o state data: The additional data on a system that is not
configuration data such as read-only status information and configuration data such as read-only status information and
collected statistics [RFC4741]. collected statistics [RFC4741].
skipping to change at page 12, line 28 skipping to change at page 13, line 28
the interaction between those nodes. the interaction between those nodes.
YANG structures data models into modules and submodules. A module YANG structures data models into modules and submodules. A module
can import data from other external modules, and include data from can import data from other external modules, and include data from
submodules. The hierarchy can be extended, allowing one module to submodules. The hierarchy can be extended, allowing one module to
add data nodes to the hierarchy defined in another module. This add data nodes to the hierarchy defined in another module. This
augmentation can be conditional, with new nodes to appearing only if augmentation can be conditional, with new nodes to appearing only if
certain conditions are met. certain conditions are met.
YANG models can describe constraints to be enforced on the data, YANG models can describe constraints to be enforced on the data,
restricting the appearance or value of nodes based the presence or restricting the appearance or value of nodes based on the presence or
value of other nodes in the hierarchy. These constraints are value of other nodes in the hierarchy. These constraints are
enforceable by either the client or the server, and valid content enforceable by either the client or the server, and valid content
must abide by them. must abide by them.
YANG defines a set of built-in types, and has a type mechanism YANG defines a set of built-in types, and has a type mechanism
through which additional types may be defined. Derived types can through which additional types may be defined. Derived types can
restrict their base type's set of valid values using mechanisms like restrict their base type's set of valid values using mechanisms like
range or pattern restrictions that can be enforced by clients or range or pattern restrictions that can be enforced by clients or
servers. They can also define usage conventions for use of the servers. They can also define usage conventions for use of the
derived type, such as a string-based type that contains a host name. derived type, such as a string-based type that contains a host name.
skipping to change at page 13, line 6 skipping to change at page 14, line 6
that imports or includes it. that imports or includes it.
YANG organizational constructs include defining lists of nodes with YANG organizational constructs include defining lists of nodes with
the same names and identifying the keys which distinguish list the same names and identifying the keys which distinguish list
members from each other. Such lists may be defined as either sorted members from each other. Such lists may be defined as either sorted
by user or automatically sorted by the system. For user-sorted by user or automatically sorted by the system. For user-sorted
lists, operations are defined for manipulating the order of the lists, operations are defined for manipulating the order of the
nodes. nodes.
YANG modules can be translated into an XML format called YIN YANG modules can be translated into an XML format called YIN
(Section 10), allowing applications using XML parsers and XSLT (Section 11), allowing applications using XML parsers and XSLT
scripts to operate on the models. scripts to operate on the models.
YANG strikes a balance between high-level object-oriented modeling YANG strikes a balance between high-level object-oriented modeling
and low-level bits-on-the-wire encoding. The reader of a YANG module and low-level bits-on-the-wire encoding. The reader of a YANG module
can easily see the high-level view of the data model while seeing how can easily see the high-level view of the data model while seeing how
the object will be encoded in NETCONF operations. the object will be encoded in NETCONF operations.
YANG is an extensible language, allowing extension statements to be YANG is an extensible language, allowing extension statements to be
defined by standards bodies, vendors, and individuals. The statement defined by standards bodies, vendors, and individuals. The statement
syntax allows these extensions to coexist with standard YANG syntax allows these extensions to coexist with standard YANG
skipping to change at page 14, line 15 skipping to change at page 15, line 15
is defined. is defined.
Submodule are partial modules that contribute derived types, Submodule are partial modules that contribute derived types,
groupings, data nodes, RPCs and notifications to a module. A module groupings, data nodes, RPCs and notifications to a module. A module
may include a number of submodules, but each submodule may belong to may include a number of submodules, but each submodule may belong to
only one module. The "include" statement allows a module or only one module. The "include" statement allows a module or
submodule to reference material in submodules, and the "import" submodule to reference material in submodules, and the "import"
statement allows references to material defined in other modules. statement allows references to material defined in other modules.
To reference an item that is defined in an external module it MUST be To reference an item that is defined in an external module it MUST be
imported. Identifiers that are neither defined nor imported MUST NOT imported. Identifiers that are neither defined, imported nor
be visible in the local module. included MUST NOT be visible in the local module.
To reference an item that is defined in one of its submodules, the To reference an item that is defined in one of its submodules, the
module MUST include the submodule. module MUST include the submodule.
A submodule that needs to reference an item defined in another A submodule that needs to reference an item defined in another
submodule of the same module, MUST include this submodule. submodule of the same module, MUST include this submodule.
There MUST NOT be any circular chains of imports or includes. For There MUST NOT be any circular chains of imports or includes. For
example, if submodule "a" includes submodule "b", "b" cannot include example, if submodule "a" includes submodule "b", "b" cannot include
"a". "a".
skipping to change at page 19, line 45 skipping to change at page 20, line 45
type uint32; type uint32;
config false; config false;
} }
} }
4.2.4. Built-in Types 4.2.4. Built-in Types
YANG has a set of built-in types, similar to those of many YANG has a set of built-in types, similar to those of many
programming languages, but with some differences due to special programming languages, but with some differences due to special
requirements from the management domain. The following table requirements from the management domain. The following table
summarizes the built-in types discussed in Section 8: summarizes the built-in types discussed in Section 9:
+---------------------+-------------+-------------------------------+ +---------------------+-------------+-------------------------------+
| Name | Type | Description | | Name | Type | Description |
+---------------------+-------------+-------------------------------+ +---------------------+-------------+-------------------------------+
| binary | Text | Any binary data |
| bits | Text/Number | A set of bits or flags |
| boolean | Text | "true" or "false" |
| empty | Empty | A leaf that does not have any |
| | | value |
| enumeration | Text/Number | Enumerated strings with |
| | | associated numeric values |
| float32 | Number | 32-bit IEEE floating point |
| | | real number |
| float64 | Number | 64-bit IEEE floating point |
| | | real number |
| identityref | Text | A reference to an abstract |
| | | identity |
| instance-identifier | Text | References a data tree node |
| int8 | Number | 8-bit signed integer | | int8 | Number | 8-bit signed integer |
| int16 | Number | 16-bit signed integer | | int16 | Number | 16-bit signed integer |
| int32 | Number | 32-bit signed integer | | int32 | Number | 32-bit signed integer |
| int64 | Number | 64-bit signed integer | | int64 | Number | 64-bit signed integer |
| keyref | Text/Number | A reference to a list's key |
| | | value |
| string | Text | Human readable string |
| uint8 | Number | 8-bit unsigned integer | | uint8 | Number | 8-bit unsigned integer |
| uint16 | Number | 16-bit unsigned integer | | uint16 | Number | 16-bit unsigned integer |
| uint32 | Number | 32-bit unsigned integer | | uint32 | Number | 32-bit unsigned integer |
| uint64 | Number | 64-bit unsigned integer | | uint64 | Number | 64-bit unsigned integer |
| float32 | Number | 32-bit IEEE floating point |
| | | real number |
| float64 | Number | 64-bit IEEE floating point |
| | | real number |
| string | Text | Human readable string |
| boolean | Text | "true" or "false" |
| enumeration | Text/Number | Enumerated strings with |
| | | associated numeric values |
| bits | Text/Number | A set of bits or flags |
| binary | Text | Any binary data |
| keyref | Text/Number | A reference to a list's key |
| | | value |
| empty | Empty | A leaf that does not have any |
| | | value |
| union | Text/Number | Choice of member types | | union | Text/Number | Choice of member types |
| instance-identifier | Text | References a data tree node |
+---------------------+-------------+-------------------------------+ +---------------------+-------------+-------------------------------+
The "type" statement is covered in Section 8. The "type" statement is covered in Section 9.
4.2.5. Derived Types (typedef) 4.2.5. Derived Types (typedef)
YANG can define derived types from base types using the "typedef" YANG can define derived types from base types using the "typedef"
statement. A base type can be either a built-in type or a derived statement. A base type can be either a built-in type or a derived
type, allowing a hierarchy of derived types. type, allowing a hierarchy of derived types.
A derived type can be used as the argument for the "type" statement. A derived type can be used as the argument for the "type" statement.
YANG Example: YANG Example:
skipping to change at page 22, line 5 skipping to change at page 23, line 5
NETCONF XML Encoding: NETCONF XML Encoding:
<peer> <peer>
<destination> <destination>
<address>192.0.2.1</address> <address>192.0.2.1</address>
<port>830</port> <port>830</port>
</destination> </destination>
</peer> </peer>
The grouping can be refined as it is used, allowing certain The grouping can be refined as it is used, allowing certain
statements to be overridden. In this example the description is statements to be overridden. In this example, the description is
refined: refined:
container connection { container connection {
container source { container source {
uses target { uses target {
leaf address { refine "address" {
description "Source IP address"; description "Source IP address";
} }
leaf port { refine "port" {
description "Source port number"; description "Source port number";
} }
} }
} }
container destination { container destination {
uses target { uses target {
leaf address { refine "address" {
description "Destination IP address"; description "Destination IP address";
} }
leaf port { refine "port" {
description "Destination port number"; description "Destination port number";
} }
} }
} }
} }
The "grouping" statement is covered in Section 7.11. The "grouping" statement is covered in Section 7.11.
4.2.7. Choices 4.2.7. Choices
skipping to change at page 25, line 15 skipping to change at page 26, line 15
<rpc message-id="101" <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<activate-software-image xmlns="http://acme.example.com/system"> <activate-software-image xmlns="http://acme.example.com/system">
<name>acmefw-2.3</name> <name>acmefw-2.3</name>
</activate-software-image> </activate-software-image>
</rpc> </rpc>
<rpc-reply message-id="101" <rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<status xmlns="http://acme.example.com/system"> <status xmlns="http://acme.example.com/system">
The image acmefw-2.3 is being installed. The image acmefw-2.3 is being installed.
</status> </status>
</data>
</rpc-reply> </rpc-reply>
The "rpc" statement is covered in Section 7.13. The "rpc" statement is covered in Section 7.13.
4.2.10. Notification Definitions 4.2.10. Notification Definitions
YANG allows the definition of notifications suitable for NETCONF. YANG allows the definition of notifications suitable for NETCONF.
YANG data definition statements are used to model the content of the YANG data definition statements are used to model the content of the
notification. notification.
YANG Example: YANG Example:
notification link-failure { notification link-failure {
description "A link failure has been detected"; description "A link failure has been detected";
leaf if-index {
type int32 { range "1 .. max"; }
}
leaf if-name { leaf if-name {
type keyref { type keyref {
path "/interfaces/interface/name"; path "/interfaces/interface/name";
} }
} }
leaf if-admin-status {
type ifAdminStatus;
}
} }
NETCONF XML Encoding: NETCONF XML Encoding:
<notification <notification
xmlns="urn:ietf:params:netconf:capability:notification:1.0"> xmlns="urn:ietf:params:netconf:capability:notification:1.0">
<eventTime>2007-09-01T10:00:00Z</eventTime> <eventTime>2007-09-01T10:00:00Z</eventTime>
<link-failure xmlns="http://acme.example.com/system"> <link-failure xmlns="http://acme.example.com/system">
<if-name>so-1/2/3.0</if-name> <if-name>so-1/2/3.0</if-name>
<if-admin-status>up</if-admin-status>
</link-failure> </link-failure>
</notification> </notification>
The "notification" statement is covered in Section 7.14. The "notification" statement is covered in Section 7.14.
5. Language Concepts 5. Language Concepts
5.1. Modules and Submodules 5.1. Modules and Submodules
The module is the base unit of definition in YANG. A module defines The module is the base unit of definition in YANG. A module defines
a single data model. A module can define a complete, cohesive model, a single data model. A module can define a complete, cohesive model,
or augment an existing data model with additional nodes. or augment an existing data model with additional nodes.
skipping to change at page 28, line 39 skipping to change at page 29, line 39
5.4. XML Namespaces 5.4. XML Namespaces
All YANG definitions are specified within a particular XML Namespace. All YANG definitions are specified within a particular XML Namespace.
Each module defines an XML namespace as a globally unique URI Each module defines an XML namespace as a globally unique URI
[RFC3986]. A NETCONF client or server uses the namespace during XML [RFC3986]. A NETCONF client or server uses the namespace during XML
encoding of data. encoding of data.
The namespace URI is advertised as a capability in the NETCONF The namespace URI is advertised as a capability in the NETCONF
<hello> message to indicate support for the YANG module by a NETCONF <hello> message to indicate support for the YANG module by a NETCONF
server. The capability URI advertised SHOULD be on the form: server. The capability URI advertised MUST be on the form:
namespace-uri "?" revision
Where "revision" is the revision of the module (see Section 7.1.9) capability-string = namespace-uri [ parameter-list ]
that the server implements. parameter-list = "?" parameter *( "&" parameter )
parameter = revision-parameter /
module-parameter /
feature-parameter /
deviation-parameter
revision-parameter = "revision=" revision-number
module-parameter = "module=" module-name
feature-parameter = "features=" feature *( "," feature )
deviation-parameter = "deviations=" deviation *( "," deviation )
Where "revision-number" is the revision of the module (see
Section 7.1.9) that the server implements, "module-name" is the name
of module as it appears in the "module" statement (see Section 7.1),
"namespace-uri" is the namespace for the module as it appears in the
"namespace" statement, "feature" is the name of an optional feature
implemented by the device (see Section 7.18.1), and "deviation" is
the name of a module defining device deviations (see Section 7.18.3).
Namespaces for standard module names will be assigned by IANA. They Namespaces for standard module names will be assigned by IANA. They
MUST be unique (but different revisions of the same module should MUST be unique (but different revisions of the same module should
have the same namespace). have the same namespace).
Namespaces for private module names will be assigned by the Namespaces for private module names will be assigned by the
organization owning the module without a central registry. It is organization owning the module without a central registry. It is
recommended to choose namespaces that will have a low probability of recommended to choose namespaces that will have a low probability of
colliding with standard or other enterprise modules, e.g. by using colliding with standard or other enterprise modules, e.g. by using
the enterprise or organization name in the namespace. the enterprise or organization name in the namespace.
skipping to change at page 32, line 5 skipping to change at page 32, line 48
Scoped definitions MUST NOT shadow definitions at a higher scope. A Scoped definitions MUST NOT shadow definitions at a higher scope. A
type or group cannot be defined if a higher level in the schema type or group cannot be defined if a higher level in the schema
hierarchy has a definition with a matching identifier. hierarchy has a definition with a matching identifier.
When a YANG implementation resolves a reference to an unprefixed type When a YANG implementation resolves a reference to an unprefixed type
or grouping, or one which uses the prefix of the local module, it or grouping, or one which uses the prefix of the local module, it
searches up the levels of hierarchy in the schema tree, starting at searches up the levels of hierarchy in the schema tree, starting at
the current level, for the definition of the type or grouping. the current level, for the definition of the type or grouping.
5.9. Conformance
Conformance is a measure of how accurately a device follows the
model. Generally speaking, devices are responsible for implementing
the model faithfully, allowing applications to treat devices which
implement the model identically. Deviations from the model can
reduce the utility of the model and increase fragility into
applications that use it.
YANG modelers have three levels of conformance:
o the basic behavior of the model
o optional features that are part of the model
o deviations from the model
We will consider each of these in sequence.
5.9.1. Basic Behavior
The model defines a contract between the client and server, which
allows both parties to have faith the other knows the syntax and
semantics behind the modeled data. The strength of YANG lies in the
strength of this contract and the mindless devotion with which
implementers follow it.
5.9.2. Optional Features
In many models, the modeler will allow sections of the model to be
conditional, based on the device. The device controls whether these
conditional portions of the model are supported or valid for that
particular device.
For example, a syslog data model may choose to include the ability to
save logs locally, but the modeler will realize that this is only
possible if the device has local storage. If there is no local
storage, an application should not tell the device to save logs.
YANG supports this conditional mechanism using a construct called
"features". A module may declare any number of features, identified
by simple strings, and may make portions of the module optional based
on those feature. If the device supports a feature, then the
corresponding portions of the module are valid for that device. If
the device doesn't support the feature, those parts of the module are
not valid, and applications should behave accordingly.
Features give the modeler a mechanism for making portions of the
module conditional in a manner that is controlled by the device. The
model can express constructs which are not universally present in all
devices. These features are included in the model definition,
allowing a consistent view and allowing applications to learn which
features are supported and tailor their behavior to the device.
Features are defined using the "feature" statement. Definitions in
the module that are conditional to the feature are noted by the "if-
feature" statement with the name of the feature as its argument.
Further details are available in Section 7.18.1.
5.9.3. Deviations
In an ideal world, all devices would be required to implement the
model exactly as defined, and deviations from the model would not be
allowed. But in the real world, devices are often not able or
willing to implement the model as written. For YANG-based automation
to deal with these device deviations, a mechanism must exist for
devices to inform applications of the specifics of such deviations.
For example, a BGP module may allow any number of BGP peers, but a
particular device may only support 16 BGP peers. Any application
configuring the 17th peer will receive an error. While an error may
suffice to let the application know it cannot add another peer, it
would be far better if the application had prior knowledge of this
limitation and could prevent the user from starting down the path
that could not succeed.
Device deviations are declared using the "deviation" statement, which
takes as its argument a string which identifies a node in the schema
tree. The contents of the statement details the manner in which the
device implementation deviates from the contract as defined in the
module.
5.9.4. Announcing Conformance Information in the <hello> Message
Devices indicate the names of supported features and device
deviations via the <hello> message. In hello messages, the features
are encoded in the "features" parameter within the URI. The value of
this parameter is a comma-separated list of feature names which the
device supports for the specific module.
<hello>
<capability>
http://example.com/mod/mcp?features=feat1&module=mcp
</capability>
<capability>
http://example.com/mod/some?module=some&features=one,two,three
</capability>
</hello>
Device deviations are announced via the "deviations" parameter. The
value of the deviations parameter is a comma-separated list of
modules containing deviations from the capability's module.
<hello>
<capability>
http://example.com/abc?deviations=my-devs
</capability>
</hello>
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 are written in the UTF-8 [RFC3629] character set. YANG modules are written in the UTF-8 [RFC3629] character set.
skipping to change at page 34, line 13 skipping to change at page 38, line 13
"first line\n" + " second line" "first line\n" + " second line"
6.2. Identifiers 6.2. Identifiers
Identifiers are used to identify different kinds of YANG items by Identifiers are used to identify different kinds of YANG items by
name. Each identifier starts with an upper-case or lower-case ASCII name. Each identifier starts with an upper-case or lower-case ASCII
letter or an underscore character, followed by zero or more ASCII letter or an underscore character, followed by zero or more ASCII
letters, digits, underscore characters, hyphens, and dots. letters, digits, underscore characters, hyphens, and dots.
Implementations MUST support identifiers up to 63 characters in Implementations MUST support identifiers up to 63 characters in
length. Identifiers are case sensitive. The identifier syntax is length. Identifiers are case sensitive. The identifier syntax is
formally defined by the rule "identifier" in Section 11. Identifiers formally defined by the rule "identifier" in Section 12. Identifiers
can be specified as quoted or unquoted strings. can be specified as quoted or unquoted strings.
6.2.1. Identifiers and their namespaces 6.2.1. Identifiers and their namespaces
Each identifier is valid in a namespace which depends on the type of Each identifier is valid in a namespace which depends on the type of
the YANG item being defined: the YANG item being defined:
o All module and submodule names share the same global module o All module and submodule names share the same global module
identifier namespace. identifier namespace.
o All extension names defined in a module and its submodules share o All extension names defined in a module and its submodules share
the same extension identifier namespace. the same extension identifier namespace.
o All feature names defined in a module and its submodules share the
same feature identifier namespace.
o All identity names defined in a module and its submodules share
the same identity identifier namespace.
o All derived type names defined within a parent node or at the top- o All derived type names defined within a parent node or at the top-
level of the module or its submodules share the same type level of the module or its submodules share the same type
identifier namespace. This namespace is scoped to the parent node identifier namespace. This namespace is scoped to the parent node
or module. or module.
o All groupings defined within a parent node or at the top-level of o All groupings defined within a parent node or at the top-level of
the module or its submodules share the same grouping identifier the module or its submodules share the same grouping identifier
namespace. This namespace is scoped to the parent node or module. namespace. This namespace is scoped to the parent node or module.
o All leafs, leaf-lists, lists, containers, choices, rpcs, and o All leafs, leaf-lists, lists, containers, choices, rpcs, and
skipping to change at page 35, line 13 skipping to change at page 39, line 19
either by a semicolon (";") or a block of substatements enclosed either by a semicolon (";") or a block of substatements enclosed
within curly braces ("{ }"): within curly braces ("{ }"):
statement = keyword [argument] (";" / "{" *statement "}") statement = keyword [argument] (";" / "{" *statement "}")
The argument is a string, as defined in Section 6.1.2. The argument is a string, as defined in Section 6.1.2.
6.3.1. Language Extensions 6.3.1. Language Extensions
A module can introduce YANG extensions by using the "extension" A module can introduce YANG extensions by using the "extension"
keyword (see Section 7.16). The extensions can be imported by other keyword (see Section 7.17). The extensions can be imported by other
modules with the "import" statement (see Section 7.1.5). When an modules with the "import" statement (see Section 7.1.5). When an
imported extension is used, the extension's keyword must be qualified imported extension is used, the extension's keyword must be qualified
using the prefix with which the extension's module was imported. If using the prefix with which the extension's module was imported. If
an extension is used in the module where it is defined, the an extension is used in the module where it is defined, the
extension's keyword must be qualified with the module's prefix. extension's keyword must be qualified with the module's prefix.
Since submodules cannot include the parent module, any extensions in
the module which need to be exposed to submodules must be defined in
a submodule. Submodules can then include this submodule to find the
definition of the extension.
6.4. XPath Evaluations 6.4. XPath Evaluations
YANG relies on XPath 1.0 [XPATH] as a notation for specifying many YANG relies on XPath 1.0 [XPATH] as a notation for specifying many
inter-node references and dependencies. NETCONF clients and servers inter-node references and dependencies. NETCONF clients and servers
are not required to implement an XPath interpreter, but MUST ensure are not required to implement an XPath interpreter, but MUST ensure
that the requirements encoded in the data model are enforced. The that the requirements encoded in the data model are enforced. The
manner of enforcement is an implementation decision. The XPath manner of enforcement is an implementation decision. The XPath
expressions MUST be valid, but any implementation may choose to expressions MUST be valid, but any implementation may choose to
implement them by hand, rather than using the XPath expression implement them by hand, rather than using the XPath expression
directly. directly.
skipping to change at page 37, line 27 skipping to change at page 41, line 27
<organization statement> <organization statement>
<contact statement> <contact statement>
<description statement> <description statement>
<reference statement> <reference statement>
// revision history // revision history
<revision statements> <revision statements>
// module definitions // module definitions
<extension statements> <extension statements>
<feature statements>
<typedef statements> <typedef statements>
<grouping statements> <grouping statements>
<container statements> <container statements>
<leaf statements> <leaf statements>
<leaf-list statements> <leaf-list statements>
<list statements> <list statements>
<choice statements> <choice statements>
<uses statements> <uses statements>
<rpc statements> <rpc statements>
<notification statements> <notification statements>
<augment statements> <augment statements>
<deviation statements>
} }
7.1.1. The module's Substatements 7.1.1. The module's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| augment | 7.15 | 0..n | | augment | 7.15 | 0..n |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| contact | 7.1.8 | 0..1 | | contact | 7.1.8 | 0..1 |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| description | 7.17.3 | 0..1 | | description | 7.19.3 | 0..1 |
| extension | 7.16 | 0..n | | deviation | 7.18.3 | 0..n |
| extension | 7.17 | 0..n |
| feature | 7.18.1 | 0..n |
| grouping | 7.11 | 0..n | | grouping | 7.11 | 0..n |
| import | 7.1.5 | 0..n | | import | 7.1.5 | 0..n |
| include | 7.1.6 | 0..n | | include | 7.1.6 | 0..n |
| leaf | 7.6 | 0..n | | leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n | | leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n | | list | 7.8 | 0..n |
| namespace | 7.1.3 | 1 | | namespace | 7.1.3 | 1 |
| notification | 7.14 | 0..n | | notification | 7.14 | 0..n |
| organization | 7.1.7 | 0..1 | | organization | 7.1.7 | 0..1 |
| prefix | 7.1.4 | 1 | | prefix | 7.1.4 | 1 |
| reference | 7.17.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| revision | 7.1.9 | 0..n | | revision | 7.1.9 | 0..n |
| rpc | 7.13 | 0..n | | rpc | 7.13 | 0..n |
| typedef | 7.3 | 0..n | | typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n | | uses | 7.12 | 0..n |
| yang-version | 7.1.2 | 0..1 | | yang-version | 7.1.2 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.1.2. The yang-version Statement 7.1.2. The yang-version Statement
The "yang-version" statement specifies which version of the YANG The "yang-version" statement specifies which version of the YANG
language was used in developing the module. The statement's argument language was used in developing the module. The statement's argument
contains value "1", which is the current yang version and the default contains value "1", which is the current yang version and the default
value. value.
This statement is intended for future-proofing the syntax of YANG This statement is intended for future-proofing the syntax of YANG
against possible changes in later versions of YANG. Since the against possible changes in later versions of YANG. Since the
current version is the default value, the statement need not appear current version is the default value, the statement need not appear
in YANG modules until a future version is defined. When a new in YANG modules until a future version is defined. When a new
version is defined, YANG modules can either use version 2 features version is defined, YANG modules can either use version 2 statements
and add the "yang-version 2" statement, or remain within the version and add the "yang-version 2" statement, or remain within the version
1 feature set and continue to use the default setting of "yang- 1 feature set and continue to use the default setting of "yang-
version 1". version 1".
7.1.3. The namespace Statement 7.1.3. The namespace Statement
The "namespace" statement defines the XML namespace for all XML The "namespace" statement defines the XML namespace for all XML
elements defined by the module. Its argument is the URI of the elements defined by the module. Its argument is the URI of the
namespace. namespace.
skipping to change at page 39, line 24 skipping to change at page 43, line 29
module, e.g. "if:ifName". A prefix follows the same rules as an module, e.g. "if:ifName". A prefix follows the same rules as an
identifier (see Section 6.2). identifier (see Section 6.2).
When used inside the "module" statement, the "prefix" statement When used inside the "module" statement, the "prefix" statement
defines the prefix to be used when this module is imported. To defines the prefix to be used when this module is imported. To
improve readability of the NETCONF XML, a NETCONF client or server improve readability of the NETCONF XML, a NETCONF client or server
which generates XML or XPath that use prefixes, the prefix defined by which generates XML or XPath that use prefixes, the prefix defined by
a module SHOULD be used, unless there is a conflict. a module SHOULD be used, unless there is a conflict.
When used inside the "import" statement, the "prefix" statement When used inside the "import" statement, the "prefix" statement
defines the prefix to be used when accessing data inside the imported defines the prefix to be used when accessing definitions inside the
module. When a reference to an identifier from the imported module imported module. When a reference to an identifier from the imported
is used, the prefix string for the module from which objects are module is used, the prefix string for the module from which objects
being imported is used in combination with a colon (":") and the are being imported is used in combination with a colon (":") and the
identifier, e.g. "if:ifIndex". To improve readability of YANG identifier, e.g. "if:ifIndex". To improve readability of YANG
modules, the prefix defined by a module SHOULD be used when the modules, the prefix defined by a module SHOULD be used when the
module is imported, unless there is a conflict. module is imported, unless there is a conflict.
All prefixes, including the prefix for the module itself MUST be All prefixes, including the prefix for the module itself MUST be
unique within the module or submodule. unique within the module or submodule.
7.1.5. The import Statement 7.1.5. The import Statement
The "import" statement makes definitions from one module available The "import" statement makes definitions from one module available
skipping to change at page 40, line 5 skipping to change at page 44, line 5
module to import, and the statement is followed by a block of module to import, and the statement is followed by a block of
substatements that holds detailed import information. substatements that holds detailed import information.
All identifiers contained in an imported module are imported into the All identifiers contained in an imported module are imported into the
current module or submodule, so that they can be referenced by current module or submodule, so that they can be referenced by
definitions in the current module or submodule. The mandatory definitions in the current module or submodule. The mandatory
"prefix" substatement assigns a prefix for the imported module which "prefix" substatement assigns a prefix for the imported module which
is scoped to the importing module or submodule. Multiple "import" is scoped to the importing module or submodule. Multiple "import"
statements may be specified to import from different modules. statements may be specified to import from different modules.
The import's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| prefix | 7.1.4 | 1 | | prefix | 7.1.4 | 1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.1.6. The include Statement 7.1.6. The include Statement
The "include" statement is used to make content from a submodule The "include" statement is used to make content from a submodule
available to the module. The argument is an identifier which is the available to the module. The argument is an identifier which is the
skipping to change at page 41, line 10 skipping to change at page 45, line 10
module SHOULD have at least one initial "revision" statement. For module SHOULD have at least one initial "revision" statement. For
every editorial change, a new one SHOULD be added in front of the every editorial change, a new one SHOULD be added in front of the
revisions sequence, so that all revisions are in reverse revisions sequence, so that all revisions are in reverse
chronological order. chronological order.
7.1.9.1. The revision's Substatement 7.1.9.1. The revision's Substatement
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| description | 7.17.3 | 0..1 | | description | 7.19.3 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.1.10. Usage Example 7.1.10. Usage Example
module acme-system { module acme-system {
namespace "http://acme.example.com/system"; namespace "http://acme.example.com/system";
prefix "acme"; prefix "acme";
import yang-types { import yang-types {
prefix "yang"; prefix "yang";
skipping to change at page 43, line 22 skipping to change at page 47, line 22
<organization statement> <organization statement>
<contact statement> <contact statement>
<description statement> <description statement>
<reference statement> <reference statement>
// revision history // revision history
<revision statements> <revision statements>
// module definitions // module definitions
<extension statements> <extension statements>
<feature statements>
<typedef statements> <typedef statements>
<grouping statements> <grouping statements>
<container statements> <container statements>
<leaf statements> <leaf statements>
<leaf-list statements> <leaf-list statements>
<list statements> <list statements>
<choice statements> <choice statements>
<uses statements> <uses statements>
<rpc statements> <rpc statements>
<notification statements> <notification statements>
<augment statements> <augment statements>
<deviation statements>
} }
7.2.1. The submodule's Substatements 7.2.1. The submodule's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| augment | 7.15 | 0..n | | augment | 7.15 | 0..n |
| belongs-to | 7.2.2 | 1 | | belongs-to | 7.2.2 | 1 |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| contact | 7.1.8 | 0..1 | | contact | 7.1.8 | 0..1 |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| description | 7.17.3 | 0..1 | | description | 7.19.3 | 0..1 |
| extension | 7.16 | 0..n | | deviation | 7.18.3 | 0..n |
| extension | 7.17 | 0..n |
| feature | 7.18.1 | 0..n |
| grouping | 7.11 | 0..n | | grouping | 7.11 | 0..n |
| import | 7.1.5 | 0..n | | import | 7.1.5 | 0..n |
| include | 7.1.6 | 0..n | | include | 7.1.6 | 0..n |
| leaf | 7.6 | 0..n | | leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n | | leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n | | list | 7.8 | 0..n |
| notification | 7.14 | 0..n | | notification | 7.14 | 0..n |
| organization | 7.1.7 | 0..1 | | organization | 7.1.7 | 0..1 |
| reference | 7.17.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| revision | 7.1.9 | 0..n | | revision | 7.1.9 | 0..n |
| rpc | 7.13 | 0..n | | rpc | 7.13 | 0..n |
| typedef | 7.3 | 0..n | | typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n | | uses | 7.12 | 0..n |
| yang-version | 7.1.2 | 0..1 | | yang-version | 7.1.2 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.2.2. The belongs-to Statement 7.2.2. The belongs-to Statement
The "belongs-to" statement specifies the module to which the The "belongs-to" statement specifies the module to which the
submodule belongs. The argument is an identifier which is the name submodule belongs. The argument is an identifier which is the name
of the module. Only the module to which a submodule belongs, or of the module. Only the module to which a submodule belongs, or
another submodule that belongs to the same module, are allowed to another submodule that belongs to the same module, are allowed to
include that submodule. include that submodule.
The mandatory "prefix" substatement assigns a prefix for the module
to which the submodule belongs. All definitions in the local
submodule and any included submodules can be accessed by using the
prefix.
The belongs-to's Substatements
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| prefix | 7.1.4 | 1 |
+--------------+---------+-------------+
7.2.3. Usage Example 7.2.3. Usage Example
submodule acme-types { submodule acme-types {
belongs-to "acme-system"; belongs-to "acme-system" {
prefix "acme";
}
import yang-types { import yang-types {
prefix "yang"; prefix "yang";
} }
organization "ACME Inc."; organization "ACME Inc.";
contact contact
"Joe L. User "Joe L. User
ACME, Inc. ACME, Inc.
skipping to change at page 46, line 13 skipping to change at page 50, line 23
submodule, the name of the type to be defined MUST be unique within submodule, the name of the type to be defined MUST be unique within
the module. For details about scoping for nested typedef, see the module. For details about scoping for nested typedef, see
Section 5.8. Section 5.8.
7.3.1. The typedef's Substatements 7.3.1. The typedef's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| default | 7.3.4 | 0..1 | | default | 7.3.4 | 0..1 |
| description | 7.17.3 | 0..1 | | description | 7.19.3 | 0..1 |
| reference | 7.17.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.17.2 | 0..1 | | status | 7.19.2 | 0..1 |
| type | 7.3.2 | 1 | | type | 7.3.2 | 1 |
| units | 7.3.3 | 0..1 | | units | 7.3.3 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.3.2. The typedef's type Statement 7.3.2. The typedef's type Statement
The "type" statement, which must be present, defines the base type The "type" statement, which must be present, defines the base type
from which this type is derived. See Section 7.4 for details. from which this type is derived. See Section 7.4 for details.
7.3.3. The units Statement 7.3.3. The units Statement
skipping to change at page 47, line 15 skipping to change at page 51, line 19
7.3.5. Usage Example 7.3.5. Usage Example
typedef listen-ipv4-address { typedef listen-ipv4-address {
type inet:ipv4-address; type inet:ipv4-address;
default "0.0.0.0"; default "0.0.0.0";
} }
7.4. The type Statement 7.4. The type Statement
The "type" statement takes as an argument a string which is the name The "type" statement takes as an argument a string which is the name
of a YANG built-in type (see Section 8) or a derived type (see of a YANG built-in type (see Section 9) or a derived type (see
Section 7.3), followed by an optional block of substatements that are Section 7.3), followed by an optional block of substatements that are
used to put further restrictions on the type. used to put further restrictions on the type.
The restrictions that can be applied depends on the type being The restrictions that can be applied depends on the type being
restricted. All restriction statements are described in conjunction restricted. All restriction statements are described in conjunction
with the built-in types in Section 8. with the built-in types in Section 9.
7.4.1. The type's Substatements 7.4.1. The type's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| bit | 8.6.3 | 0..n | | bit | 9.7.4 | 0..n |
| enum | 8.5.3 | 0..n | | enum | 9.6.4 | 0..n |
| length | 8.3.3 | 0..1 | | length | 9.4.4 | 0..1 |
| path | 8.8.2 | 0..1 | | path | 9.9.2 | 0..1 |
| pattern | 8.3.5 | 0..n | | pattern | 9.4.6 | 0..n |
| range | 8.1.3 | 0..1 | | range | 9.2.4 | 0..1 |
| type | 7.4 | 0..n | | type | 7.4 | 0..n |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.5. The container Statement 7.5. The container Statement
The "container" statement is used to define an interior node in the The "container" statement is used to define an interior node in the
schema tree. It takes one argument, which is an identifier, followed schema tree. It takes one argument, which is an identifier, followed
by a block of substatements that holds detailed container by a block of substatements that holds detailed container
information. information.
skipping to change at page 48, line 13 skipping to change at page 52, line 18
the existence of the container in the data tree. the existence of the container in the data tree.
7.5.1. The container's Substatements 7.5.1. The container's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| augment | 7.15 | 0..n | | augment | 7.15 | 0..n |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| config | 7.17.1 | 0..1 | | config | 7.19.1 | 0..1 |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| description | 7.17.3 | 0..1 | | description | 7.19.3 | 0..1 |
| grouping | 7.11 | 0..n | | grouping | 7.11 | 0..n |
| if-feature | 7.18.2 | 0..n |
| leaf | 7.6 | 0..n | | leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n | | leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n | | list | 7.8 | 0..n |
| must | 7.5.2 | 0..n | | must | 7.5.2 | 0..n |
| presence | 7.5.4 | 0..1 | | presence | 7.5.4 | 0..1 |
| reference | 7.17.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.17.2 | 0..1 | | status | 7.19.2 | 0..1 |
| typedef | 7.3 | 0..n | | typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n | | uses | 7.12 | 0..n |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.5.2. The must Statement 7.5.2. The must Statement
The "must" statement, which is optional, takes as an argument a The "must" statement, which is optional, takes as an argument a
string which contains an XPath expression. It is used to formally string which contains an XPath expression. It is used to formally
declare a constraint on the configuration data. When a configuration declare a constraint on valid data. The constraint is enforced
datastore is validated, all "must" constraints are conceptually according to the rules in Section 8.
evaluated once for each corresponding instance in the datastore's
data tree, and for all leafs with default values in effect. If an
instance does not exist in the data tree, and it does not have a
default value, its "must" statements are not evaluated.
All such constraints MUST evaluate to true for the configuration to When a data is validated, all "must" constraints are conceptually
be valid. evaluated once for each corresponding instance in the data tree, and
for all leafs with default values in effect. If an instance does not
exist in the data tree, and it does not have a default value, its
"must" statements are not evaluated.
All such constraints MUST evaluate to true for the data to be valid.
The "must" statement is ignored if the data does not represent The "must" statement is ignored if the data does not represent
configuration. configuration.
The XPath expression is conceptually evaluated in the following The XPath expression is conceptually evaluated in the following
context: context:
o The context node is the node in the data tree for which the "must" o The context node is the node in the data tree for which the "must"
statement is defined. statement is defined.
skipping to change at page 49, line 22 skipping to change at page 53, line 31
[XPATH], and a function "current()" which returns a node set with [XPATH], and a function "current()" which returns a node set with
the initial context node. the initial context node.
The result of the XPath expression is converted to a boolean value The result of the XPath expression is converted to a boolean value
using the standard XPath rules. using the standard XPath rules.
If the node with the must statement represents configuration data, If the node with the must statement represents configuration data,
any node referenced in the XPath expression MUST also represent any node referenced in the XPath expression MUST also represent
configuration. configuration.
Note that the XPath expression is conceptually evaluated. This means Note that since all leaf values in the data tree are conceptually
that an implementation does not have to use an XPath evaluator on the stored in their canonical form (see Section 7.6 and Section 7.7), any
device. How the evaluation is done in practice is an implementation XPath comparisons are done on the canonical value.
decision.
Also note that the XPath expression is conceptually evaluated. This
means that an implementation does not have to use an XPath evaluator
on the device. How the evaluation is done in practice is an
implementation decision.
7.5.3. The must's Substatements 7.5.3. The must's Substatements
+---------------+---------+-------------+ +---------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+---------------+---------+-------------+ +---------------+---------+-------------+
| description | 7.17.3 | 0..1 | | description | 7.19.3 | 0..1 |
| error-app-tag | 7.5.3.2 | 0..1 | | error-app-tag | 7.5.3.2 | 0..1 |
| error-message | 7.5.3.1 | 0..1 | | error-message | 7.5.3.1 | 0..1 |
| reference | 7.17.4 | 0..1 | | reference | 7.19.4 | 0..1 |
+---------------+---------+-------------+ +---------------+---------+-------------+
7.5.3.1. The error-message Statement 7.5.3.1. The error-message Statement
The "error-message" statement, which is optional, takes a string as The "error-message" statement, which is optional, takes a string as
an argument. If the constraint evaluates to false, the string is an argument. If the constraint evaluates to false, the string is
passed as <error-message> in the <rpc-error>. passed as <error-message> in the <rpc-error>.
7.5.3.2. The error-app-tag Statement 7.5.3.2. The error-app-tag Statement
skipping to change at page 52, line 40 skipping to change at page 57, line 12
</edit-config> </edit-config>
</rpc> </rpc>
7.6. The leaf Statement 7.6. The leaf Statement
The "leaf" statement is used to define a leaf node in the schema The "leaf" statement is used to define a leaf node in the schema
tree. It takes one argument, which is an identifier, followed by a tree. It takes one argument, which is an identifier, followed by a
block of substatements that holds detailed leaf information. block of substatements that holds detailed leaf information.
A leaf node has a value, but no child nodes in the data tree. A leaf node has a value, but no child nodes in the data tree.
Conceptually, the value in the data tree is always in the canonical
form (see Section 9.1).
A leaf node exists in zero or one instances in the data tree, A leaf node exists in zero or one instances in the data tree,
depending on the value of the "mandatory" statement. depending on the value of the "mandatory" statement.
The "leaf" statement is used to define a scalar variable of a The "leaf" statement is used to define a scalar variable of a
particular built-in or derived type. particular built-in or derived type.
If a leaf has a "default" statement, the leaf's default value is set If a leaf has a "default" statement, the leaf's default value is set
to the value of the "default" statement. Otherwise, if the leaf's to the value of the "default" statement. Otherwise, if the leaf's
type has a default value, and the leaf is not mandatory, then the type has a default value, and the leaf is not mandatory, then the
skipping to change at page 53, line 14 skipping to change at page 58, line 10
If the leaf has a default value, the server MUST use this value If the leaf has a default value, the server MUST use this value
internally if no value is provided by the NETCONF client when the internally if no value is provided by the NETCONF client when the
instance is created. instance is created.
7.6.1. The leaf's Substatements 7.6.1. The leaf's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| config | 7.17.1 | 0..1 | | config | 7.19.1 | 0..1 |
| default | 7.6.3 | 0..1 | | default | 7.6.3 | 0..1 |
| description | 7.17.3 | 0..1 | | description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| mandatory | 7.6.4 | 0..1 | | mandatory | 7.6.4 | 0..1 |
| must | 7.5.2 | 0..n | | must | 7.5.2 | 0..n |
| reference | 7.17.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.17.2 | 0..1 | | status | 7.19.2 | 0..1 |
| type | 7.6.2 | 1 | | type | 7.6.2 | 1 |
| units | 7.3.3 | 0..1 | | units | 7.3.3 | 0..1 |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.6.2. The leaf's type Statement 7.6.2. The leaf's type Statement
The "type" statement, which must be present, takes as an argument the The "type" statement, which must be present, takes as an argument the
name of an existing built-in or derived type. The optional name of an existing built-in or derived type. The optional
substatements specify restrictions on this type. See Section 7.4 for substatements specify restrictions on this type. See Section 7.4 for
details. details.
7.6.3. The leaf's default Statement 7.6.3. The leaf's default Statement
skipping to change at page 53, line 46 skipping to change at page 58, line 44
The value of the "default" statement MUST correspond to the type The value of the "default" statement MUST correspond to the type
specified in the leaf's "type" statement. 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.
7.6.4. The leaf's mandatory Statement 7.6.4. 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". If "mandatory" is "true", the node the string "true" or "false". If not specified, the default is
must exist in a valid configuration if its parent node exists. Since "false".
containers without a "presence" statement are implicitly created and
deleted when needed, they are ignored when performing mandatory tests
for leafs. A mandatory leaf within such a container is mandatory
even if the container's data node does not exist.
If not specified, the default is "false". If "mandatory" is "true", the node MUST exist if its parent node
exists. This constraint is enforced according to the rules in
Section 8.
Since containers without a "presence" statement are implicitly
created and deleted when needed, they are ignored when performing
mandatory tests for leafs. A mandatory leaf within such a container
is mandatory even if the container's data node does not exist.
7.6.5. XML Encoding Rules 7.6.5. XML Encoding Rules
A leaf node is encoded as an XML element. The element's name is the A leaf node is encoded as an XML element. The element's name is the
leaf's identifier, and its XML namespace is the module's XML leaf's identifier, and its XML namespace is the module's XML
namespace. namespace.
The value of the leaf node is encoded to XML according to the type, The value of the leaf node is encoded to XML according to the type,
and sent as character data in the element. and sent as character data in the element.
skipping to change at page 55, line 39 skipping to change at page 60, line 39
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. The values in a leaf-list MUST be unique.
Conceptually, the values in the data tree are always in the canonical
form (see Section 9.1).
If the type referenced by the leaf-list has a default value, it has If the type referenced by the leaf-list has a default value, it has
no effect in the leaf-list. no effect in the leaf-list.
7.7.1. The leaf-list's Substatements 7.7.1. The leaf-list's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| config | 7.17.1 | 0..1 | | config | 7.19.1 | 0..1 |
| description | 7.17.3 | 0..1 | | description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| max-elements | 7.7.3 | 0..1 | | max-elements | 7.7.3 | 0..1 |
| min-elements | 7.7.2 | 0..1 | | min-elements | 7.7.2 | 0..1 |
| must | 7.5.2 | 0..n | | must | 7.5.2 | 0..n |
| ordered-by | 7.7.4 | 0..1 | | ordered-by | 7.7.4 | 0..1 |
| reference | 7.17.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.17.2 | 0..1 | | status | 7.19.2 | 0..1 |
| type | 7.4 | 1 | | type | 7.4 | 1 |
| units | 7.3.3 | 0..1 | | units | 7.3.3 | 0..1 |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.7.2. The min-elements Statement 7.7.2. The min-elements Statement
The "min-elements" statement, which is optional, takes as an argument The "min-elements" statement, which is optional, takes as an argument
a non-negative integer which puts a constraint on a valid a non-negative integer which puts a constraint on valid list entries.
configuration. A valid configuration always has at least min- A valid leaf-list or list always has at least min-elements entries.
elements values in the leaf-list or list.
If no "min-elements" statement is present, it defaults to zero. If no "min-elements" statement is present, it defaults to zero.
The "min-elements" constraint is enforced according to the rules in
Section 8.
7.7.3. The max-elements Statement 7.7.3. The max-elements Statement
The "max-elements" statement, which is optional, takes as an argument The "max-elements" statement, which is optional, takes as an argument
a positive integer or the string "unbounded", which puts a constraint a positive integer or the string "unbounded", which puts a constraint
on a valid configuration. A valid configuration always has at most on valid list entries. A valid leaf-list or list always has at most
max-elements values in the leaf-list or list. max-elements entries.
If no "max-elements" statement is present, it defaults to If no "max-elements" statement is present, it defaults to
"unbounded". "unbounded".
The "max-elements" constraint is enforced according to the rules in
Section 8.
7.7.4. The ordered-by Statement 7.7.4. The ordered-by Statement
The "ordered-by" statement defines whether the order of entries The "ordered-by" statement defines whether the order of entries
within a list are determined by the user or the system. The argument within a list are determined by the user or the system. The argument
is one of the strings "system" or "user". If not present, order is one of the strings "system" or "user". If not present, order
defaults to "system". defaults to "system".
This statement is ignored if the list represents state data, RPC
output parameters, or notification content.
See Section 5.5 for additional information. See Section 5.5 for additional information.
7.7.4.1. ordered-by system 7.7.4.1. ordered-by system
The entries in the list are sorted according to an unspecified order. The entries in the list are sorted according to an unspecified order.
Thus an implementation is free to sort the entries in the most Thus an implementation is free to sort the entries in the most
appropriate order. An implementation SHOULD use the same order for appropriate order. An implementation SHOULD use the same order for
the same data, regardless of how the data were created. Using a the same data, regardless of how the data were created. Using a
deterministic order will makes comparisons possible using simple deterministic order will makes comparisons possible using simple
tools like "diff". tools like "diff".
skipping to change at page 59, line 4 skipping to change at page 64, line 23
<system xmlns="http://example.com/schema/config"> <system xmlns="http://example.com/schema/config">
<services> <services>
<ssh> <ssh>
<allow-user>eric</allow-user> <allow-user>eric</allow-user>
</ssh> </ssh>
</services> </services>
</system> </system>
</config> </config>
</edit-config> </edit-config>
</rpc> </rpc>
Given the following ordered-by user leaf-list: Given the following ordered-by user leaf-list:
leaf-list ciphers { leaf-list cipher {
type string; type string;
ordered-by user; ordered-by user;
description "A list of ciphers"; description "A list of ciphers";
} }
The following would be used to insert a new cipher "blowfish-cbc" The following would be used to insert a new cipher "blowfish-cbc"
after "3des-cbc": after "3des-cbc":
<rpc message-id="101" <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
skipping to change at page 60, line 6 skipping to change at page 66, line 4
Each such instance is known as a list entry. The "list" statement Each such instance is known as a list entry. The "list" statement
takes one argument which is an identifier, followed by a block of takes one argument which is an identifier, followed by a block of
substatements that holds detailed list information. substatements that holds detailed list information.
A list entry is uniquely identified by the values of the list's keys. A list entry is uniquely identified by the values of the list's keys.
A list is similar to a table where each list entry is a row in the A list is similar to a table where each list entry is a row in the
table. table.
7.8.1. The list's Substatements 7.8.1. The list's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| augment | 7.15 | 0..n | | augment | 7.15 | 0..n |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| config | 7.17.1 | 0..1 | | config | 7.19.1 | 0..1 |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| description | 7.17.3 | 0..1 | | description | 7.19.3 | 0..1 |
| grouping | 7.11 | 0..n | | grouping | 7.11 | 0..n |
| if-feature | 7.18.2 | 0..n |
| key | 7.8.2 | 0..1 | | key | 7.8.2 | 0..1 |
| leaf | 7.6 | 0..n | | leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n | | leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n | | list | 7.8 | 0..n |
| max-elements | 7.7.3 | 0..1 | | max-elements | 7.7.3 | 0..1 |
| min-elements | 7.7.2 | 0..1 | | min-elements | 7.7.2 | 0..1 |
| must | 7.5.2 | 0..n | | must | 7.5.2 | 0..n |
| ordered-by | 7.7.4 | 0..1 | | ordered-by | 7.7.4 | 0..1 |
| reference | 7.17.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.17.2 | 0..1 | | status | 7.19.2 | 0..1 |
| typedef | 7.3 | 0..n | | typedef | 7.3 | 0..n |
| unique | 7.8.3 | 0..n | | unique | 7.8.3 | 0..n |
| uses | 7.12 | 0..n | | uses | 7.12 | 0..n |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.8.2. The list's key Statement 7.8.2. The list's key Statement
The "key" statement, which MUST be present if the list represents The "key" statement, which MUST be present if the list represents
configuration, and MAY be present otherwise, takes as an argument a configuration, and MAY be present otherwise, takes as an argument a
string which specifies a space separated list of leaf identifiers of string which specifies a space separated list of leaf identifiers of
this list. A leaf identifier MUST NOT appear more than once in the this list. A leaf identifier MUST NOT appear more than once in the
key. Each such leaf identifier MUST refer to a child leaf of the key. Each such leaf identifier MUST refer to a child leaf of the
list. list.
skipping to change at page 61, line 6 skipping to change at page 67, line 6
leafs or their types are ignored. It also implies that any mandatory leafs or their types are ignored. It also implies that any mandatory
statement in the key leafs are ignored. statement in the key leafs are ignored.
A leaf that is part of the key can be of any built-in or derived A leaf that is part of the key can be of any built-in or derived
type, except it MUST NOT be the built-in type "empty". type, except it MUST NOT be the built-in type "empty".
All key leafs in a list MUST have the same value for their "config" All key leafs in a list MUST have the same value for their "config"
as the list itself. as the list itself.
The key string syntax is formally defined by the rule "key-arg" in The key string syntax is formally defined by the rule "key-arg" in
Section 11. Section 12.
7.8.3. The lists's unique Statement 7.8.3. The lists's unique Statement
The "unique" statement is used to put constraints on valid The "unique" statement is used to put constraints on valid list
configurations. It takes as an argument a string which contains a entries. It takes as an argument a string which contains a space
space separated list of schema node identifiers, which MUST be given separated list of schema node identifiers, which MUST be given in the
in the descendant form (see the rule "descendant-schema-nodeid" in descendant form (see the rule "descendant-schema-nodeid" in
Section 11). Each such schema node identifier MUST refer to a leaf. Section 12). Each such schema node identifier MUST refer to a leaf.
In a valid configuration, the combined values of all the leaf If one of the referenced leafs represents configuration data, then
instances specified in the string MUST be unique within all list all of the referenced leafs MUST represent configuration data.
entry instances.
The "unique" constraint specifies that the combined values of all the
leaf instances specified in the argument string, including leafs with
default values, MUST be unique within all list entry instances. The
constraint is enforced according to the rules in Section 8.
The unique string syntax is formally defined by the rule "unique-arg" The unique string syntax is formally defined by the rule "unique-arg"
in Section 11. in Section 12.
7.8.3.1. Usage Example 7.8.3.1. Usage Example
With the following list: With the following list:
list server { list server {
key "name"; key "name";
unique "ip port"; unique "ip port";
leaf name { leaf name {
type string; type string;
skipping to change at page 62, line 44 skipping to change at page 69, line 6
In an "ordered-by user" list, the attributes "insert" and "key" in In an "ordered-by user" list, the attributes "insert" and "key" in
the YANG namespace (Section 5.4.1) can be used to control where in the YANG namespace (Section 5.4.1) can be used to control where in
the list the entry is inserted. These can be used during "create" the list the entry is inserted. These can be used during "create"
operations to insert a new list entry, or during "merge" or "replace" operations to insert a new list entry, or during "merge" or "replace"
operations to insert a new list entry or move an existing one. operations to insert a new list entry or move an existing one.
The "insert" attribute can take the values "first", "last", "before", The "insert" attribute can take the values "first", "last", "before",
and "after". If the value is "before" or "after", the "key" and "after". If the value is "before" or "after", the "key"
attribute must also be used, to specify an existing element in the attribute must also be used, to specify an existing element in the
list. The value of the "key" attribute is the key predicates of the list. The value of the "key" attribute is the key predicates of the
full instance identifier (see Section 8.11) for the list entry. full instance identifier (see Section 9.13) for the list entry.
If no "insert" attribute is present in the "create" operation, it If no "insert" attribute is present in the "create" operation, it
defaults to "last". defaults to "last".
In a <copy-config>, or an <edit-config> with a "replace" operation In a <copy-config>, or an <edit-config> with a "replace" operation
which covers the entire list, the list entry order is the same as the which covers the entire list, the list entry order is the same as the
order of the XML elements in the request. order of the XML elements in the request.
7.8.7. Usage Example 7.8.7. Usage Example
skipping to change at page 66, line 28 skipping to change at page 73, line 12
See Section 4.2.7 for additional information. See Section 4.2.7 for additional information.
7.9.1. The choice's Substatements 7.9.1. The choice's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| case | 7.9.2 | 0..n | | case | 7.9.2 | 0..n |
| config | 7.17.1 | 0..1 | | config | 7.19.1 | 0..1 |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| default | 7.9.3 | 0..1 | | default | 7.9.3 | 0..1 |
| description | 7.17.3 | 0..1 | | description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| leaf | 7.6 | 0..n | | leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n | | leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n | | list | 7.8 | 0..n |
| mandatory | 7.9.4 | 0..1 | | mandatory | 7.9.4 | 0..1 |
| reference | 7.17.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.17.2 | 0..1 | | status | 7.19.2 | 0..1 |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.9.2. The choice's case Statement 7.9.2. The choice's case Statement
The "case" statement is used to define branches of the choice. It The "case" statement is used to define branches of the choice. It
takes as an argument an identifier, followed by a block of takes as an argument an identifier, followed by a block of
substatements that holds detailed case information. substatements that holds detailed case information.
The identifier is used to identify the case node in the schema tree. The identifier is used to identify the case node in the schema tree.
A case node does not exist in the data tree. A case node does not exist in the data tree.
skipping to change at page 68, line 13 skipping to change at page 74, line 29
The case identifier MUST be unique within a choice. The case identifier MUST be unique within a choice.
7.9.2.1. The case's Substatements 7.9.2.1. The case's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| augment | 7.15 | 0..n | | augment | 7.15 | 0..n |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| description | 7.17.3 | 0..1 | | description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| leaf | 7.6 | 0..n | | leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n | | leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n | | list | 7.8 | 0..n |
| reference | 7.17.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.17.2 | 0..1 | | status | 7.19.2 | 0..1 |
| uses | 7.12 | 0..n | | uses | 7.12 | 0..n |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.9.3. The choice's default Statement 7.9.3. The choice's default Statement
The "default" statement indicates if a case should be considered as The "default" statement indicates if a case should be considered as
the default if no child nodes from any of the choice's cases exists. the default if no child nodes from any of the choice's cases exists.
The argument is the identifier of the "case" statement. If the The argument is the identifier of the "case" statement. If the
"default" statement is missing, there is no default case. "default" statement is missing, there is no default case.
The "default" statement MUST NOT be present on choices where The "default" statement MUST NOT be present on choices where
"mandatory" is true. "mandatory" is true.
The default case is only important when considering the default The default case is only important when considering the default
values of nodes under the cases. The default values for nodes under values of nodes under the cases. The default values for nodes under
the default case are used if none of the nodes under any of the cases the default case are used if none of the nodes under any of the cases
are present. are present.
There MUST NOT be any mandatory nodes (Section 3.1) under the default There MUST NOT be any mandatory nodes (Section 3.1) directly under
case. the default case.
Default values for child nodes under a case are only used if one of Default values for child nodes under a case are only used if one of
the nodes under that case is present, or if that case is the default the nodes under that case is present, or if that case is the default
case. If none of the nodes under a case are present and the case is case. If none of the nodes under a case are present and the case is
not the default case, the default values of the cases' child nodes not the default case, the default values of the cases' child nodes
are ignored. are ignored.
In this example, the choice defaults to "interval", and the default In this example, the choice defaults to "interval", and the default
value will be used if none of "daily", "time-of-day", or "manual" are value will be used if none of "daily", "time-of-day", or "manual" are
present. If "daily" is present, the default value for "time-of-day" present. If "daily" is present, the default value for "time-of-day"
skipping to change at page 69, line 37 skipping to change at page 76, line 9
type empty; type empty;
} }
} }
} }
} }
7.9.4. The choice's mandatory Statement 7.9.4. The choice's mandatory Statement
The "mandatory" statement, which is optional, takes as an argument The "mandatory" statement, which is optional, takes as an argument
the string "true" or "false". If "mandatory" is "true", at least one the string "true" or "false". If "mandatory" is "true", at least one
node from exactly one of the choice's case branches MUST exist in a node from exactly one of the choice's case branches MUST exist. This
valid configuration. If "mandatory" is "false", a valid constraint is enforced according to the rules in Section 8.
configuration MAY have no nodes from the choice's case branches
present.
If not specified, the default is "false". If not specified, the default is "false".
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.
7.9.6. NETCONF <edit-config> operations 7.9.6. NETCONF <edit-config> operations
Since only one of the choices cases can be valid at any time, the Since only one of the choices cases can be valid at any time, the
skipping to change at page 71, line 26 skipping to change at page 78, line 10
An anyxml node cannot be augmented. An anyxml node cannot be augmented.
It is NOT RECOMMENDED that the anyxml statement is used to represent It is NOT RECOMMENDED that the anyxml statement is used to represent
configuration data. configuration data.
7.10.1. The anyxml's Substatements 7.10.1. The anyxml's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| config | 7.17.1 | 0..1 | | config | 7.19.1 | 0..1 |
| description | 7.17.3 | 0..1 | | description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| mandatory | 7.6.4 | 0..1 | | mandatory | 7.6.4 | 0..1 |
| reference | 7.17.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.17.2 | 0..1 | | status | 7.19.2 | 0..1 |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.10.2. XML Encoding Rules 7.10.2. XML Encoding Rules
An anyxml node is encoded as an XML element. The element's name is An anyxml node is encoded as an XML element. The element's name is
the anyxml's identifier, and its XML namespace is the module's XML the anyxml's identifier, and its XML namespace is the module's XML
namespace. The value of the anyxml node is encoded as XML content of namespace. The value of the anyxml node is encoded as XML content of
this element. this element.
Note that any prefixes used in the encoding are local to each Note that any prefixes used in the encoding are local to each
skipping to change at page 74, line 14 skipping to change at page 80, line 18
7.11.1. The grouping's Substatements 7.11.1. The grouping's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| augment | 7.15 | 0..n | | augment | 7.15 | 0..n |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| description | 7.17.3 | 0..1 | | description | 7.19.3 | 0..1 |
| grouping | 7.11 | 0..n | | grouping | 7.11 | 0..n |
| leaf | 7.6 | 0..n | | leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n | | leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n | | list | 7.8 | 0..n |
| reference | 7.17.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.17.2 | 0..1 | | status | 7.19.2 | 0..1 |
| typedef | 7.3 | 0..n | | typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n | | uses | 7.12 | 0..n |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.11.2. Usage Example 7.11.2. Usage Example
import inet-types { import inet-types {
prefix "inet"; prefix "inet";
} }
skipping to change at page 75, line 10 skipping to change at page 81, line 14
then updated according to the refinement statements. Thus, the then updated according to the refinement statements. Thus, the
identifiers defined in the grouping are copied into the current identifiers defined in the grouping are copied into the current
module's namespace, even if the grouping is imported from some other module's namespace, even if the grouping is imported from some other
module. module.
7.12.1. The uses's Substatements 7.12.1. The uses's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | augment | 7.15 | 0..1 |
| choice | 7.9 | 0..n | | description | 7.19.3 | 0..1 |
| container | 7.5 | 0..n | | if-feature | 7.18.2 | 0..n |
| description | 7.17.3 | 0..1 | | refine | 7.12.2 | 0..1 |
| leaf | 7.6 | 0..n | | reference | 7.19.4 | 0..1 |
| leaf-list | 7.7 | 0..n | | status | 7.19.2 | 0..1 |
| list | 7.8 | 0..n | | when | 7.19.5 | 0..1 |
| reference | 7.17.4 | 0..1 |
| status | 7.17.2 | 0..1 |
| uses | 7.12 | 0..n |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.12.2. The uses's Refinement Statements 7.12.2. The refine Statement
Some of the properties of each node in the grouping can be refined in Some of the properties of each node in the grouping can be refined
substatements to "uses". If a node is not present in a substatement, with the "refine" statement. The argument is a a string which
it is not refined, and thus used exactly as it was defined in the identifies a node in the grouping. This node is called the refine's
"grouping". A node can be refined only once in "uses". target node. If a node in the grouping is not present as target node
of a refine statement, it is not refined, and thus used exactly as it
was defined in the grouping.
The argument string is a schema node identifier. The syntax is
formally defined by the rule "descendant-schema-nodeid" in
Section 12.
The following refinements can be done: The following refinements can be done:
o A leaf or choice node may get a default value, or a new default o A leaf or choice node may get a default value, or a new default
value if it already had one. value if it already had one.
o Any node may get a specialized "description" string. o Any node may get a specialized "description" string.
o Any node may get a specialized "reference" string. o Any node may get a specialized "reference" string.
skipping to change at page 76, line 17 skipping to change at page 82, line 23
Each node in the grouping is encoded as if it was defined inline, Each node in the grouping is encoded as if it was defined inline,
even if it is imported from another module with another XML even if it is imported from another module with another XML
namespace. namespace.
7.12.4. Usage Example 7.12.4. Usage Example
To use the "address" grouping defined in Section 7.11.2 in a To use the "address" grouping defined in Section 7.11.2 in a
definition of an HTTP server in some other module, we can do: definition of an HTTP server in some other module, we can do:
import acme-system { import acme-system {
prefix acme; prefix "acme";
} }
container http-server { container http-server {
leaf name { leaf name {
type string; type string;
} }
uses acme:address; uses acme:address;
} }
A corresponding XML encoding: A corresponding XML encoding:
skipping to change at page 76, line 43 skipping to change at page 82, line 49
</http-server> </http-server>
If port 80 should be the default for the HTTP server, default can be If port 80 should be the default for the HTTP server, default can be
added: added:
container http-server { container http-server {
leaf name { leaf name {
type string; type string;
} }
uses acme:address { uses acme:address {
leaf port { refine port {
default 80; default 80;
} }
} }
} }
If we want to define a list of servers, and each server has the ip If we want to define a list of servers, and each server has the ip
and port as keys, we can do: and port as keys, we can do:
list server { list server {
key "ip port"; key "ip port";
skipping to change at page 78, line 10 skipping to change at page 84, line 10
The "rpc" statement defines an rpc node in the schema tree. Under The "rpc" statement defines an rpc node in the schema tree. Under
the rpc node, an input node with the name "input", and an output node the rpc node, an input node with the name "input", and an output node
with the name "output" are also defined. The nodes "input" and with the name "output" are also defined. The nodes "input" and
"output" are defined in the module's namespace. "output" are defined in the module's namespace.
7.13.1. The rpc's Substatements 7.13.1. The rpc's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| description | 7.17.3 | 0..1 | | description | 7.19.3 | 0..1 |
| grouping | 7.11 | 0..n | | grouping | 7.11 | 0..n |
| if-feature | 7.18.2 | 0..n |
| input | 7.13.2 | 0..1 | | input | 7.13.2 | 0..1 |
| output | 7.13.3 | 0..1 | | output | 7.13.3 | 0..1 |
| reference | 7.17.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.17.2 | 0..1 | | status | 7.19.2 | 0..1 |
| typedef | 7.3 | 0..n | | typedef | 7.3 | 0..n |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.13.2. The input Statement 7.13.2. The input Statement
The "input" statement, which is optional, is used to define input The "input" statement, which is optional, is used to define input
parameters to the RPC method. It does not take an argument. The parameters to the RPC method. It does not take an argument. The
substatements to "input" defines nodes under the RPC's input node. substatements to "input" defines nodes under the RPC's input node.
If a container in the input tree has a "presence" statement, the If a container in the input tree has a "presence" statement, the
container need not be present in a NETCONF RPC invocation. container need not be present in a NETCONF RPC invocation.
If a leaf in the input tree has a "mandatory" statement with the If a leaf in the input tree has a "mandatory" statement with the
value "true", the leaf MUST be present in a NETCONF RPC invocation. value "true", the leaf MUST be present in a NETCONF RPC invocation.
If a leaf in the input tree has a default value, the NETCONF server If a leaf in the input tree has a default value, the NETCONF server
MUST internally use this default if the leaf is not present in a MUST internally use this default if the leaf is not present in a
NETCONF RPC invocation. NETCONF RPC invocation.
If a "config" or "must" statement is present for any node in the If a "config" statement is present for any node in the input tree, it
input tree, it is ignored. is ignored.
7.13.2.1. The input's Substatements 7.13.2.1. The input's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| augment | 7.15 | 0..n | | augment | 7.15 | 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 79, line 38 skipping to change at page 85, line 38
If a container in the output tree has a "presence" statement, the If a container in the output tree has a "presence" statement, the
container need not be present in a NETCONF RPC reply container need not be present in a NETCONF RPC reply
If a leaf in the output tree has a "mandatory" statement with the If a leaf in the output tree has a "mandatory" statement with the
value "true", the leaf MUST be present in a NETCONF RPC reply. value "true", the leaf MUST be present in a NETCONF RPC reply.
If a leaf in the output tree has a default value, the NETCONF client If a leaf in the output tree has a default value, the NETCONF client
MUST internally use this default if the leaf is not present in a MUST internally use this default if the leaf is not present in a
NETCONF RPC reply. NETCONF RPC reply.
If a "config" or "must" statement is present for any node in the If a "config" statement is present for any node in the output tree,
output tree, it is ignored. it is ignored.
7.13.3.1. The output's Substatements 7.13.3.1. The output's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| augment | 7.15 | 0..n | | augment | 7.15 | 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 80, line 44 skipping to change at page 86, line 44
[RFC4741]. If output parameters are returned, they are encoded as [RFC4741]. If output parameters are returned, they are encoded as
child elements to the <rpc-reply> element defined in [RFC4741], in child elements to the <rpc-reply> element defined in [RFC4741], in
the same order as they are defined within the output statement. the same order as they are defined within the output statement.
7.13.5. Usage Example 7.13.5. Usage Example
The following example defines an RPC method: The following example defines an RPC method:
module rock { module rock {
namespace "http://example.net/rock"; namespace "http://example.net/rock";
prefix rock; prefix "rock";
rpc rock-the-house { rpc rock-the-house {
input { input {
leaf zip-code { leaf zip-code {
type string; type string;
} }
} }
} }
} }
skipping to change at page 81, line 38 skipping to change at page 87, line 38
If a container in the notification tree has a "presence" statement, If a container in the notification tree has a "presence" statement,
the container need not be present in a NETCONF notification. the container need not be present in a NETCONF notification.
If a leaf in the notification tree has a "mandatory" statement with If a leaf in the notification tree has a "mandatory" statement with
the value "true", the leaf MUST be present in a NETCONF notification. the value "true", the leaf MUST be present in a NETCONF notification.
If a leaf in the notification tree has a default value, the NETCONF If a leaf in the notification tree has a default value, the NETCONF
server MUST internally use this default if the leaf is not present in server MUST internally use this default if the leaf is not present in
a NETCONF notification. a NETCONF notification.
If a "config" or "must" statement is present for any node in the If a "config" statement is present for any node in the notification
notification tree, it is ignored. tree, it is ignored.
7.14.1. The notification's Substatements 7.14.1. The notification's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| augment | 7.15 | 0..n | | augment | 7.15 | 0..n |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| description | 7.17.3 | 0..1 | | description | 7.19.3 | 0..1 |
| grouping | 7.11 | 0..n | | grouping | 7.11 | 0..n |
| if-feature | 7.18.2 | 0..n |
| leaf | 7.6 | 0..n | | leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n | | leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n | | list | 7.8 | 0..n |
| reference | 7.17.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.17.2 | 0..1 | | status | 7.19.2 | 0..1 |
| typedef | 7.3 | 0..n | | typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n | | uses | 7.12 | 0..n |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.14.2. XML Encoding Rules 7.14.2. XML Encoding Rules
A notification node is encoded as a child XML element to the A notification node is encoded as a child XML element to the
<notification> element defined in [RFC5277]. The element's name is <notification> element defined in [RFC5277]. The element's name is
the notification's identifier, and its XML namespace is the module's the notification's identifier, and its XML namespace is the module's
XML namespace. XML namespace.
skipping to change at page 83, line 8 skipping to change at page 89, line 8
notification node's XML element, in the same order as they are notification node's XML element, in the same order as they are
defined within the notification statement. defined within the notification statement.
7.14.3. Usage Example 7.14.3. Usage Example
The following example defines a notification: The following example defines a notification:
module event { module event {
namespace "http://example.com/event"; namespace "http://example.com/event";
prefix ev; prefix "ev";
notification event { notification event {
leaf event-class { leaf event-class {
type string; type string;
} }
anyxml reporting-entity; anyxml reporting-entity;
leaf severity { leaf severity {
type string; type string;
} }
} }
skipping to change at page 83, line 45 skipping to change at page 89, line 45
7.15. The augment Statement 7.15. The augment Statement
The "augment" statement allows a module or submodule to add to the The "augment" statement allows a module or submodule to add to the
schema tree defined in another module or submodule. The argument is schema tree defined in another module or submodule. The argument is
a string which identifies a node in the schema tree. This node is a string which identifies a node in the schema tree. This node is
called the augment's target node. The target node MUST be either a called the augment's target node. The target node MUST be either a
container, list, choice, case, input, output, or notification node. container, list, choice, case, input, output, or notification node.
It is augmented with the nodes defined in the substatements that It is augmented with the nodes defined in the substatements that
follow the "augment" statement. follow the "augment" statement.
The augment string is a schema node identifier. The syntax is The argument string is a schema node identifier. The syntax is
formally defined by the rule "augment-arg" in Section 11. If the formally defined by the rule "augment-arg" in Section 12. If the
"augment" statement is on the top-level in a module or submodule, the "augment" statement is on the top-level in a module or submodule, the
absolute form (defined by the rule "absolute-schema-nodeid" in absolute form (defined by the rule "absolute-schema-nodeid" in
Section 11) of a schema node identifier MAY be used. Otherwise, the Section 12) of a schema node identifier MUST be used. If the
descendant form (defined by the rule "descendant-schema-nodeid" in "augment" statement is in a "uses" statement, the descendant form
Section 11) MUST be used. (defined by the rule "descendant-schema-nodeid" in Section 12) MUST
be used.
The syntax for a schema node identifier is a subset of the XPath The syntax for a schema node identifier is a subset of the XPath
syntax. It is an absolute or relative XPath location path in syntax. It is an absolute or relative XPath location path in
abbreviated syntax, where axes and predicates are not permitted. abbreviated syntax, where axes and predicates are not permitted.
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.
skipping to change at page 84, line 30 skipping to change at page 90, line 30
7.15.1. The augment's Substatements 7.15.1. The augment's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| augment | 7.15 | 0..n | | augment | 7.15 | 0..n |
| case | 7.9.2 | 0..n | | case | 7.9.2 | 0..n |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| description | 7.17.3 | 0..1 | | description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| leaf | 7.6 | 0..n | | leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n | | leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n | | list | 7.8 | 0..n |
| reference | 7.17.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.17.2 | 0..1 | | status | 7.19.2 | 0..1 |
| uses | 7.12 | 0..n | | uses | 7.12 | 0..n |
| when | 7.15.2 | 0..1 | | when | 7.19.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.15.2. The when Statement 7.15.2. XML Encoding Rules
The "when" statement allows the augmentation to be conditional, with
the nodes only being valid when a specific criteria is satisfied.
The statement's argument is an XPath expression, which is used to
formally specify constraints on which instances in the data tree will
be augmented by this statement. If the XPath expression conceptually
evaluates to "true" for a particular instance, then it is augmented,
otherwise it is not.
The XPath expression is conceptually evaluated in the following
context:
o 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 closest ancestor node to the target node which is also a data
node.
o The accessible tree is made up of all nodes in the data tree, and
all leafs with default values.
o The set of namespace declarations is the set of all "import"
statements' prefix and namespace pairs, and the "prefix"
statement's prefix for the "namespace" statement's URI.
o Elements without a namespace refer to nodes in the current module.
o The function library is the core function library defined in
[XPATH], and a function "current()" which returns a node set with
the initial context node.
The result of the XPath expression is converted to a boolean value
using the standard XPath rules.
Note that the XPath expression is conceptually evaluated. This means
that an implementation does not have to use an XPath evaluator on the
device. The augment can very well be implemented with specially
written code.
7.15.3. XML Encoding Rules
All data nodes defined in the "augment" statement are defined as XML All data nodes defined in the "augment" statement are defined as XML
elements in the XML namespace of the module where the "augment" is elements in the XML namespace of the module where the "augment" is
specified. specified.
When a node is augmented, the augmented child nodes are encoded after When a node is augmented, the augmented child nodes are encoded after
all normal child nodes. If the node is augmented more than once, the all normal child nodes. If the node is augmented more than once, the
blocks of augmented child nodes are sorted (in alphanumeric order) blocks of augmented child nodes are sorted (in alphanumeric order)
according to their namespace URI and name of the first child node in according to their namespace URI and name of the first child node in
each block. each block.
7.15.4. Usage Example 7.15.3. Usage Example
In namespace http://example.com/schema/interfaces, we have: In namespace http://example.com/schema/interfaces, we have:
container interfaces { container interfaces {
list ifEntry { list ifEntry {
key "ifIndex"; key "ifIndex";
leaf ifIndex { leaf ifIndex {
type uint32; type uint32;
} }
skipping to change at page 86, line 27 skipping to change at page 91, line 31
} }
leaf ifMtu { leaf ifMtu {
type int32; type int32;
} }
} }
} }
Then in namespace http://example.com/schema/ds0, we have: Then in namespace http://example.com/schema/ds0, we have:
import interface-module { import interface-module {
prefix if; prefix "if";
} }
augment "/if:interfaces/if:ifEntry" { augment "/if:interfaces/if:ifEntry" {
when "if:ifType='ds0'"; when "if:ifType='ds0'";
leaf ds0ChannelNumber { leaf ds0ChannelNumber {
type ChannelNumber; type ChannelNumber;
} }
} }
A corresponding XML encoding: A corresponding XML encoding:
skipping to change at page 87, line 32 skipping to change at page 93, line 5
</ex:system> </ex:system>
or or
<ex:system> <ex:system>
<ex:protocol> <ex:protocol>
<other:smtp/> <other:smtp/>
</ex:protocol> </ex:protocol>
</ex:system> </ex:system>
7.16. The extension Statement 7.16. The identity Statement
The "identity" statement is used to define a new globally unique,
abstract and untyped identity. Its only purpose is to denote its
name, semantics, and existence. An identity can be defined either
from scratch or derived from a base identity. The identity's
argument is an identifier that is the name of the identity. It is
followed by a block of substatements that holds detailed identity
information.
The built-in datatype "identityref" (see Section 9.10) can be used to
reference identities within a data model.
7.16.1. The identity's Substatements
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| base | 7.16.2 | 0..1 |
| description | 7.19.3 | 0..1 |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
+--------------+---------+-------------+
7.16.2. The base Statement
The base statement, which is optional, takes as an argument a string
which is the name of an existing identity, from which the new
identity is derived. If no base statement is present, the identity
is defined from scratch.
If a prefix is present on the base name, it refers to an identity
defined in the module which was imported with that prefix, or the
local module if the prefix matches the local module's prefix.
Otherwise an identity with the matching name must be defined in the
current module or an included submodule.
Since submodules cannot include the parent module, any identities in
the module which need to be exposed to submodules must be defined in
a submodule. Submodules can then include this submodule to find the
definition of the identity.
7.16.3. Usage Example
module crypto-base {
namespace "http://example.com/crypto-base";
prefix "crypto";
identitiy crypto-alg {
description
"Base identity from which all crypto algorithms
are derived.";
}
}
}
module des {
namespace "http://example.com/des";
prefix "des";
import "crypto-base" {
prefix "crypto";
}
identity des {
base "crypto:crypto-alg";
description "DES crypto algorithm";
}
identity des3 {
base "crypto:crypto-alg";
description "Triple DES crypto algorithm";
}
}
7.17. 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
statement is to define a keyword, so that it can be imported and used statement is to define a keyword, so that it can be imported and used
by other modules. by other modules.
skipping to change at page 88, line 6 skipping to change at page 95, line 11
The extension can be used like a normal YANG statement, with the The extension can be used like a normal YANG statement, with the
statement name followed by an argument if one is defined by the statement name followed by an argument if one is defined by the
extension, and an optional block of substatements. The statement's extension, and an optional block of substatements. The statement's
name is created by combining the the prefix of the module in which name is created by combining the the prefix of the module in which
the extension was defined, a colon (":"), and the extension's the extension was defined, a colon (":"), and the extension's
keyword, with no interleaving whitespace. The substatements of an keyword, with no interleaving whitespace. The substatements of an
extension are defined by the extension, using some mechanism outside extension are defined by the extension, using some mechanism outside
the scope of this specification. Syntactically, the substatements the scope of this specification. Syntactically, the substatements
MUST be core YANG statements, or also defined using "extension" MUST be core YANG statements, or also defined using "extension"
statements. Core YANG statements in extensions MUST follow the statements. Core YANG statements in extensions MUST follow the
syntactical rules in Section 11. syntactical rules in Section 12.
7.16.1. The extension's Substatements 7.17.1. The extension's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| argument | 7.16.2 | 0..1 | | argument | 7.17.2 | 0..1 |
| description | 7.17.3 | 0..1 | | description | 7.19.3 | 0..1 |
| reference | 7.17.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.17.2 | 0..1 | | status | 7.19.2 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.16.2. The argument Statement 7.17.2. The argument Statement
The "argument" statement, which is optional, takes as an argument a The "argument" statement, which is optional, takes as an argument a
string which is the name of the argument to the keyword. If no string which is the name of the argument to the keyword. If no
argument statement is present, the keyword expects no argument when argument statement is present, the keyword expects no argument when
it is used. it is used.
The argument's name is used in the YIN mapping, where it is used as The argument's name is used in the YIN mapping, where it is used as
an XML attribute or element name, depending on the argument's text an XML attribute or element name, depending on the argument's text
statement. statement.
7.16.2.1. The argument's Substatements 7.17.2.1. The argument's Substatements
+--------------+----------+-------------+ +--------------+----------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+----------+-------------+ +--------------+----------+-------------+
| yin-element | 7.16.2.2 | 0..1 | | yin-element | 7.17.2.2 | 0..1 |
+--------------+----------+-------------+ +--------------+----------+-------------+
7.16.2.2. The yin-element Statement 7.17.2.2. The yin-element Statement
The "yin-element" statement, which is optional, takes as an argument The "yin-element" statement, which is optional, takes as an argument
the string "true" or "false". This statement indicates if the the string "true" or "false". This statement indicates if the
argument should be mapped to an XML element in YIN or to an XML argument should be mapped to an XML element in YIN or to an XML
attribute. (see Section 10). attribute. (see Section 11).
If no "yin-element" statement is present, it defaults to "false". If no "yin-element" statement is present, it defaults to "false".
7.16.3. Usage Example 7.17.3. Usage Example
To define an extension: To define an extension:
module my-extensions { module my-extensions {
... ...
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
skipping to change at page 89, line 32 skipping to change at page 96, line 36
prefix "myext"; prefix "myext";
} }
... ...
container interfaces { container interfaces {
... ...
myext:c-define "MY_INTERFACES"; myext:c-define "MY_INTERFACES";
} }
} }
7.17. Common Statements 7.18. Conformance-related Statements
This section defines statements related to conformance, as described
in Section 5.9.
7.18.1. The feature Statement
The "feature" statement is used to define a mechanism by which
portions of the schema are marked as conditional. A feature name is
defined that can later be referenced using the "if-feature" statement
(see Section 7.18.2). Schema nodes tagged with a feature are ignored
unless the device supports the given feature. This allows portions
of the YANG module to be conditional based on conditions on the
device. The model can represent the abilities of the device within
the model, giving a richer model that allows for differing device
abilities and roles.
The argument to the "feature" statement is the name of the new
feature, and follows the rules for identifiers in Section 6.2. This
name is used by the "if-feature" statement to tie the schema nodes to
the feature.
In this example, a feature called "local-storage" represents the
ability for a device to store syslog messages on local storage of
some sort. This feature is used to make the "local-storage-limit"
leaf conditional on the presence of some sort of local-storage. If
the device does not report that it supports this feature, the local-
storage-limit node is not supported.
module my-syslog {
...
feature local-storage {
description "This feature means the device supports local
storage (memory, flash or disk) that can be used to
store syslog messages.";
}
container syslog {
leaf local-storage-limit {
if-feature local-storage;
config false;
description "The amount of local storage that can be
used to hold syslog messages.";
}
}
}
The "if-feature" statement can be used in many places within the YANG
syntax. Definitions tagged with "if-feature" are ignored when the
device does not support that feature.
7.18.1.1. The feature's Substatements
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| status | 7.19.2 | 0..1 |
| reference | 7.19.4 | 0..1 |
+--------------+---------+-------------+
7.18.2. The if-feature Statement
The "if-feature" statement is used to mark portions of the model as
conditional. The argument is the name of a feature, as defined by a
"feature" statement. If a prefix is present on the feature name, it
refers to a feature defined the module which was imported with that
prefix, or the local module if the prefix matches the local module's
prefix. Otherwise a feature with the matching name must be defined
in the current module or an included submodule.
Since submodules cannot include the parent module, any features in
the module which need to be exposed to submodules must be defined in
a submodule. Submodules can then include this submodule to find the
definition of the feature.
7.18.3. The deviation Statement
The deviation statement defines a hierarchy of the module which the
device does not implement faithfully. The argument is a string that
identifies the node in the schema tree where a deviation from the
module occurs. This node is called the deviation's target node. The
contents of the deviation statement give details about the deviation.
The argument's syntax is formally defined by the rule "deviation-arg"
in Section 12.
Deviations define the way a device or class of devices deviate from
the standard. This means that deviations MUST never be part of a
published standard, since they are the mechanism for learning how
implementations vary from the standards.
Device deviations are strongly discouraged and should only be used as
a last resort. Telling the application how a device fails to follow
the standard is no substitute for implementing the standard directly.
However in some cases the cost of following the standard is heavy and
the payoff may be small. A particular device may not have the
hardware or software ability to support parts of a standard module.
When this occurs, the device makes a choice to treat attempts to
configure unsupported parts of the module as either an error that is
reported back to the unsuspecting application, or ignore that
incoming requests. Neither choice is acceptable.
Instead, YANG allows devices to document portions of the base module
which are not supported or supported but with different syntax, by
using the "deviation" statement.
7.18.3.1. The deviation's Substatements
+--------------+----------+-------------+
| substatement | section | cardinality |
+--------------+----------+-------------+
| description | 7.19.3 | 0..1 |
| deviate | 7.18.3.2 | 0..n |
| reference | 7.19.4 | 0..1 |
+--------------+----------+-------------+
7.18.3.2. The deviate Statement
The "deviate" statement defines how the device's implementation of
the target node deviates from its original definition. The argument
is one of the strings "not-supported", "add", "replace", or "delete".
The argument "not-supported" indicates that the target node is not
implemented by this device.
The argument "add" adds properties to the target node. The
properties to add are identified as a substatement to the "deviate"
statement. If the property can only appear once, the property MUST
NOT exist in the target node.
The argument "replace" replaces properties of the target node. The
properties to replace are identified by substatements to the
"deviate" statement. The property to replace MUST exist in the
target node.
The argument "delete" deletes properties from the target node. The
properties to delete are identified by substatement to "delete". The
substatement's keyword MUST match a corresponding keyword in the
target node, and the argument's string MUST be equal to the
corresponding keyword's argument string in the target node.
The deviates's Substatements
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| config | 7.19.1 | 0..1 |
| default | 7.6.3 | 0..1 |
| mandatory | 7.6.4 | 0..1 |
| max-elements | 7.7.3 | 0..1 |
| min-elements | 7.7.2 | 0..1 |
| must | 7.5.2 | 0..n |
| type | 7.4 | 0..1 |
| unique | 7.8.3 | 0..n |
| units | 7.3.3 | 0..1 |
+--------------+---------+-------------+
7.18.3.3. Usage Example
In this example, the device is informing client applications that it
does not support the old RFC867-style "daytime" service.
deviation /base:system/base:daytime {
deviate not-supported;
}
The following example sets a device-specific default value to a leaf
that does not have a default value defined:
deviation /base:system/base:user/base:type {
deviate add {
default "admin"; // new users are 'admin' by default
}
}
In this example, the device limits the number of name servers to 3:
deviation /base:system/base:name-server {
deviate replace {
max-elements 3;
}
}
If the original definition is:
container system {
must "daytime or time";
...
}
a device might remove this must constraint by doing:
deviation "/base:system" {
deviate delete {
must "daytime or time";
}
}
7.19. Common Statements
This section defines sub-statements common to several other This section defines sub-statements common to several other
statements. statements.
7.17.1. The config Statement 7.19.1. The config Statement
The "config" statement takes as an argument the string "true" or The "config" statement takes as an argument the string "true" or
"false". If "config" is "true", the definition represents "false". If "config" is "true", the definition represents
configuration, and will be part of the reply to a <get-config> configuration, and will be part of the reply to a <get-config>
request, and may be sent in a <copy-config> or <edit-config> request. request, and may be sent in a <copy-config> or <edit-config> request.
If "config" is "false", it represents state data, and will be part of If "config" is "false", it represents state data, and will be part of
the reply to a <get>, but not to a <get-config> request. the reply to a <get>, but not to a <get-config> request.
If "config" is not specified, the default is the same as the parent If "config" is not specified, the default is the same as the parent
node's (in the data model) "config" value. If the top node does not node's (in the data model) "config" value. If the top node does not
specify a "config" statement, the default is "true". specify a "config" statement, the default is "true".
If a node has "config" "false", no node underneath it can have If a node has "config" "false", no node underneath it can have
"config" set to "true". "config" set to "true".
7.17.2. The status Statement 7.19.2. The status Statement
The "status" statement takes as an argument one of the strings The "status" statement takes as an argument one of the strings
"current", "deprecated", or "obsolete". "current", "deprecated", or "obsolete".
o "current" means that the definition is current and valid. o "current" means that the definition is current and valid.
o "deprecated" indicates an obsolete definition, but it permits new/ o "deprecated" indicates an obsolete definition, but it permits new/
continued implementation in order to foster interoperability with continued implementation in order to foster interoperability with
older/existing implementations. older/existing implementations.
skipping to change at page 90, line 27 skipping to change at page 102, line 8
implemented and/or can be removed if previously implemented. implemented and/or can be removed if previously implemented.
If no status is specified, the default is "current". If no status is specified, the default is "current".
If a definition is "current", it MUST NOT reference a "deprecated" or If a definition is "current", it MUST NOT reference a "deprecated" or
"obsolete" definition within the same module. "obsolete" definition within the same module.
If a definition is "deprecated", it MUST NOT reference an "obsolete" If a definition is "deprecated", it MUST NOT reference an "obsolete"
definition within the same module. definition within the same module.
7.17.3. The description Statement 7.19.3. The description Statement
The "description" statement takes as an argument a string which The "description" statement takes as an argument a string which
contains a high-level textual description of this definition. contains a high-level textual description of this definition.
7.17.4. The reference Statement 7.19.4. The reference Statement
The "reference" statement takes as an argument a string which is used The "reference" statement takes as an argument a string which is used
to specify a textual cross-reference to an external document, either to specify a textual cross-reference to an external document, either
another module which defines related management information, or a another module which defines related management information, or a
document which provides additional information relevant to this document which provides additional information relevant to this
definition. definition.
8. Built-in Types 7.19.5. The when Statement
The "when" statement allows a data definition statement to be
conditional, with the node(s) defined by the data defined statement
only being valid when a specific criteria is satisfied. The
statement's argument is an XPath expression, which is used to
formally specify this criteria. If the XPath expression conceptually
evaluates to "true" for a particular instance, then the nodes defined
by the data definition statement are valid, otherwise they are not.
The XPath expression is conceptually evaluated in the following
context:
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 target node is a data node. Otherwise, the context node is
the closest ancestor node to the target node which is also a data
node.
o If the "when" statement is a child of a "choice" or "case"
statement, then the context node is the closest ancestor node to
the "choice" or "case" node which is also a data node.
o If the "when" statement is a child of any other data definition
statement, teh context node is the data definition's node in the
data tree.
o The accessible tree is made up of all nodes in the data tree, and
all leafs with default values.
o The set of namespace declarations is the set of all "import"
statements' prefix and namespace pairs, and the "prefix"
statement's prefix for the "namespace" statement's URI.
o Elements without a namespace refer to nodes in the current module.
o The function library is the core function library defined in
[XPATH], and a function "current()" which returns a node set with
the initial context node.
The result of the XPath expression is converted to a boolean value
using the standard XPath rules.
Note that the XPath expression is conceptually evaluated. This means
that an implementation does not have to use an XPath evaluator on the
device. The augment can very well be implemented with specially
written code.
8. Constraints
Several YANG statements define constraints on valid data. These
constraints are enforced at different times, depending on what type
of data the statement defines.
If the constraint is defined on configuration data, it MUST be true
in a valid configuration data tree.
If the constraint is defined on state data, it MUST be true in a
reply to the <get> command.
If the constraint is defined on notification content, it MUST be true
in any notification instance.
If the constraint is defined on RPC input parameters, it MUST be true
in an invocation of the RPC method.
If the constraint is defined on RPC output parameters, it MUST be
true in the RPC reply.
9. Built-in Types
YANG has a set of built-in types, similar to those of many YANG has a set of built-in types, similar to those of many
programming languages, but with some differences due to special programming languages, but with some differences due to special
requirements from the management information model. requirements from the management information model.
Additional types may be defined, derived from those built-in types or Additional types may be defined, derived from those built-in types or
from other derived types. Derived types may use subtyping to from other derived types. Derived types may use subtyping to
formally restrict the set of possible values. formally restrict the set of possible values.
The different built-in types and their derived types allow different The different built-in types and their derived types allow different
kinds of subtyping, namely length and regular expression restrictions kinds of subtyping, namely length and regular expression restrictions
of strings (Section 8.3.3, Section 8.3.5) and range restrictions of of strings (Section 9.4.4, Section 9.4.6) and range restrictions of
numeric types (Section 8.1.3). numeric types (Section 9.2.4).
The lexicographic representation of a value of a certain type is used The lexicographic representation of a value of a certain type is used
in the XML encoding over NETCONF, and when specifying default values in the XML encoding over NETCONF, and when specifying default values
in a YANG module. in a YANG module.
8.1. The Integer Built-in Types 9.1. Canonical representation
For each type, there is a single canonical representation of the
type's values. Some types allow multiple lexicographic
representations of the same value, for example the positive integer
"17" can be represented as "+17" or "17".
9.2. The Integer Built-in Types
The integer built-in types are int8, int16, int32, int64, uint8, The integer built-in types are int8, int16, int32, int64, uint8,
uint16, uint32, and uint64. They represent signed and unsigned uint16, uint32, and uint64. They represent signed and unsigned
integers of different sizes: integers of different sizes:
int8 represents integer values between -128 and 127, inclusively. int8 represents integer values between -128 and 127, inclusively.
int16 represents integer values between -32768 and 32767, int16 represents integer values between -32768 and 32767,
inclusively. inclusively.
skipping to change at page 92, line 5 skipping to change at page 106, line 13
uint8 represents integer values between 0 and 255, inclusively. uint8 represents integer values between 0 and 255, inclusively.
uint16 represents integer values between 0 and 65535, inclusively. uint16 represents integer values between 0 and 65535, inclusively.
uint32 represents integer values between 0 and 4294967295, uint32 represents integer values between 0 and 4294967295,
inclusively. inclusively.
uint64 represents integer values between 0 and 18446744073709551615, uint64 represents integer values between 0 and 18446744073709551615,
inclusively. inclusively.
8.1.1. Lexicographic Representation 9.2.1. Lexicographic Representation
An integer value is lexicographically represented as an optional sign An integer value is lexicographically represented as an optional sign
("+" or "-"), followed by a sequence of decimal digits. If no sign ("+" or "-"), followed by a sequence of decimal digits. If no sign
is specified, "+" is assumed. is specified, "+" is assumed.
For convenience, when specifying a default value for an integer in a For convenience, when specifying a default value for an integer in a
YANG module, an alternative lexicographic representation can be used, YANG module, an alternative lexicographic representation can be used,
which represents the value in a hexadecimal or octal notation. The which represents the value in a hexadecimal or octal notation. The
hexadecimal notation consists of an optional sign ("+" or "-"), the hexadecimal notation consists of an optional sign ("+" or "-"), the
characters "0x" followed a number of hexadecimal digits, where characters "0x" followed a number of hexadecimal digits, where
skipping to change at page 92, line 33 skipping to change at page 106, line 41
+4711 // legal positive value +4711 // legal positive value
4711 // legal positive value 4711 // legal positive value
-123 // legal negative value -123 // legal negative value
0xf00f // legal positive hexadecimal value 0xf00f // legal positive hexadecimal value
-0xf // legal negative hexadecimal value -0xf // legal negative hexadecimal value
052 // legal positive octal value 052 // legal positive octal value
// illegal values // illegal values
- 1 // illegal intermediate space - 1 // illegal intermediate space
8.1.2. Restrictions 9.2.2. Canonical Form
The canonical form of a positive integer does not include the sign
"+".
9.2.3. Restrictions
All integer types can be restricted with the "range" statement All integer types can be restricted with the "range" statement
(Section 8.1.3). (Section 9.2.4).
8.1.3. The range Statement 9.2.4. The range Statement
The "range" statement, which is an optional substatement to the The "range" statement, which is an optional substatement to the
"type" statement, takes as an argument a range expression string. It "type" statement, takes as an argument a range expression string. It
is used to restrict integer and floating point built-in types, or is used to restrict integer and floating point built-in types, or
types derived from those. types derived from those.
A range consists of an explicit value, or a lower inclusive bound, A range consists of an explicit value, or a lower inclusive bound,
two consecutive dots "..", and an upper inclusive bound. Multiple two consecutive dots "..", and an upper inclusive bound. Multiple
values or ranges can be given, separated by "|". If multiple values values or ranges can be given, separated by "|". If multiple values
or ranges are given they all MUST be disjoint and MUST be in or ranges are given they all MUST be disjoint and MUST be in
skipping to change at page 93, line 11 skipping to change at page 107, line 27
restricted type, the new restriction MUST be equal or more limiting, restricted type, the new restriction MUST be equal or more limiting,
that is raising the lower bounds, reducing the upper bounds, removing that is raising the lower bounds, reducing the upper bounds, removing
explicit values or ranges, or splitting ranges into multiple ranges explicit values or ranges, or splitting ranges into multiple ranges
with intermediate gaps. Each explicit value and range boundary value with intermediate gaps. Each explicit value and range boundary value
given in the range expression MUST match the type being restricted, given in the range expression MUST match the type being restricted,
or be one of the special values "min" or "max". "min" and "max" means or be one of the special values "min" or "max". "min" and "max" means
the minimum and maximum value accepted for the type being restricted, the minimum and maximum value accepted for the type being restricted,
respectively. respectively.
The range expression syntax is formally defined by the rule "range- The range expression syntax is formally defined by the rule "range-
arg" in Section 11. arg" in Section 12.
8.1.3.1. The range's Substatements 9.2.4.1. The range's Substatements
+---------------+---------+-------------+ +---------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+---------------+---------+-------------+ +---------------+---------+-------------+
| description | 7.17.3 | 0..1 | | description | 7.19.3 | 0..1 |
| error-app-tag | 7.5.3.2 | 0..1 | | error-app-tag | 7.5.3.2 | 0..1 |
| error-message | 7.5.3.1 | 0..1 | | error-message | 7.5.3.1 | 0..1 |
| reference | 7.17.4 | 0..1 | | reference | 7.19.4 | 0..1 |
+---------------+---------+-------------+ +---------------+---------+-------------+
8.1.4. Usage Example 9.2.5. Usage Example
typedef my-base-int32-type { typedef my-base-int32-type {
type int32 { type int32 {
range "1..4 | 10..20"; range "1..4 | 10..20";
} }
} }
type my-base-int32-type { type my-base-int32-type {
// legal range restriction // legal range restriction
range "11..max"; // 11..20 range "11..max"; // 11..20
} }
type int32 { type my-base-int32-type {
// illegal range restriction // illegal range restriction
range "11..100"; range "11..100";
} }
8.2. The Floating Point Built-in Types 9.3. The Floating Point Built-in Types
The floating point built-in types are float32 and float64. They The floating point built-in types are float32 and float64. They
represent floating point values of single and double precision as represent floating point values of single and double precision as
defined in [IEEE.754]. Special values are positive and negative defined in [IEEE.754]. Special values are positive and negative
infinity, and not-a-number. infinity, and not-a-number.
8.2.1. Lexicographic Representation 9.3.1. Lexicographic Representation
A floating point value is lexicographically represented as consisting A floating point value is lexicographically represented as consisting
of a decimal mantissa followed, optionally, by the character "E" or of a decimal mantissa followed, optionally, by the character "E" or
"e", followed by an integer exponent. The special values positive "e", followed by an integer exponent. The special values positive
and negative infinity and not-a-number have lexical representations and negative infinity and not-a-number have lexical representations
INF, -INF and NaN, respectively. The minimal value accepted for a INF, -INF and NaN, respectively. The minimal value accepted for a
float is -INF, and the maximal value accepted for a float is INF. float is -INF, and the maximal value accepted for a float is INF.
8.2.2. Restrictions 9.3.2. Canonical Form
[Editor's Note: TBD]
9.3.3. Restrictions
All floating point types can be restricted with the "range" statement All floating point types can be restricted with the "range" statement
(Section 8.1.3). (Section 9.2.4).
8.2.3. Usage Example 9.3.4. Usage Example
type float32 { type float32 {
range "1..4.5 | 10 | 20..INF"; range "1..4.5 | 10 | 20..INF";
} }
is equivalent to is equivalent to
type float32 { type float32 {
range "1..4.5 | 10 | 20..max"; range "1..4.5 | 10 | 20..max";
} }
8.3. The string Built-in Type 9.4. The string Built-in Type
The string built-in type represents human readable strings in YANG. The string built-in type represents human readable strings in YANG.
Legal characters are tab, carriage return, line feed, and the legal Legal characters are tab, carriage return, line feed, and the legal
characters of Unicode and ISO/IEC 10646 [ISO.10646]: characters of Unicode and ISO/IEC 10646 [ISO.10646]:
// any Unicode character, excluding the surrogate blocks, // any Unicode character, excluding the surrogate blocks,
// FFFE, and FFFF. // FFFE, and FFFF.
string = *char string = *char
char = %x9 / %xA / %xD / %x20-DFFF / %xE000-FFFD / char = %x9 / %xA / %xD / %x20-DFFF / %xE000-FFFD /
%x10000-10FFFF %x10000-10FFFF
8.3.1. Lexicographic Representation 9.4.1. Lexicographic Representation
A string value is lexicographically represented as character data in A string value is lexicographically represented as character data in
the XML encoding. the XML encoding.
8.3.2. Restrictions 9.4.2. Canonical Form
A string can be restricted with the "length" (Section 8.3.3) and The canonical form is the same as the lexicographical representation.
"pattern" (Section 8.3.5) statements. No Unicode normalization is performed of string values.
8.3.3. The length Statement 9.4.3. Restrictions
A string can be restricted with the "length" (Section 9.4.4) and
"pattern" (Section 9.4.6) statements.
9.4.4. The length Statement
The "length" statement, which is an optional substatement to the The "length" statement, which is an optional substatement to the
"type" statement, takes as an argument a length expression string. "type" statement, takes as an argument a length expression string.
It is used to restrict the built-in type "string", or types derived It is used to restrict the built-in type "string", or types derived
from "string". from "string".
A "length" statement restricts the number of characters in the A "length" statement restricts the number of characters in the
string. string.
A length range consists of an explicit value, or a lower bound, two A length range consists of an explicit value, or a lower bound, two
skipping to change at page 95, line 31 skipping to change at page 110, line 21
MUST be equal or more limiting, that is, raising the lower bounds, MUST be equal or more limiting, that is, raising the lower bounds,
reducing the upper bounds, removing explicit length values or ranges, reducing the upper bounds, removing explicit length values or ranges,
or splitting ranges into multiple ranges with intermediate gaps. A or splitting ranges into multiple ranges with intermediate gaps. A
length value is a non-negative integer, or one of the special values length value is a non-negative integer, or one of the special values
"min" or "max". "min" and "max" means the minimum and maximum length "min" or "max". "min" and "max" means the minimum and maximum length
accepted for the type being restricted, respectively. An accepted for the type being restricted, respectively. An
implementation is not required to support a length value larger than implementation is not required to support a length value larger than
18446744073709551615. 18446744073709551615.
The length expression syntax is formally defined by the rule "length- The length expression syntax is formally defined by the rule "length-
arg" in Section 11. arg" in Section 12.
8.3.3.1. The length's Substatements 9.4.4.1. The length's Substatements
+---------------+---------+-------------+ +---------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+---------------+---------+-------------+ +---------------+---------+-------------+
| description | 7.17.3 | 0..1 | | description | 7.19.3 | 0..1 |
| error-app-tag | 7.5.3.2 | 0..1 | | error-app-tag | 7.5.3.2 | 0..1 |
| error-message | 7.5.3.1 | 0..1 | | error-message | 7.5.3.1 | 0..1 |
| reference | 7.17.4 | 0..1 | | reference | 7.19.4 | 0..1 |
+---------------+---------+-------------+ +---------------+---------+-------------+
8.3.4. Usage Example 9.4.5. Usage Example
typedef my-base-str-type { typedef my-base-str-type {
type string { type string {
length "1..255"; length "1..255";
} }
} }
type my-base-str-type { type my-base-str-type {
// legal length refinement // legal length refinement
length "11 | 42..max"; // 11 | 42..255 length "11 | 42..max"; // 11 | 42..255
} }
type my-base-str-type { type my-base-str-type {
// illegal length refinement // illegal length refinement
length "1..999"; length "1..999";
} }
8.3.5. The pattern Statement 9.4.6. The pattern Statement
The "pattern" statement, which is an optional substatement to the The "pattern" statement, which is an optional substatement to the
"type" statement, takes as an argument a regular expression string, "type" statement, takes as an argument a regular expression string,
as defined in [XSD-TYPES]. It is used to restrict the built-in type as defined in [XSD-TYPES]. It is used to restrict the built-in type
"string", or types derived from "string", to values that completely "string", or types derived from "string", to values that completely
matches the pattern. matches the pattern.
If the type has multiple "pattern" statements, the expressions are If the type has multiple "pattern" statements, the expressions are
AND:ed together, i.e. all such expressions have to match. AND:ed together, i.e. all such expressions have to match.
8.3.5.1. The pattern's Substatements 9.4.6.1. The pattern's Substatements
+---------------+---------+-------------+ +---------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+---------------+---------+-------------+ +---------------+---------+-------------+
| description | 7.17.3 | 0..1 | | description | 7.19.3 | 0..1 |
| error-app-tag | 7.5.3.2 | 0..1 | | error-app-tag | 7.5.3.2 | 0..1 |
| error-message | 7.5.3.1 | 0..1 | | error-message | 7.5.3.1 | 0..1 |
| reference | 7.17.4 | 0..1 | | reference | 7.19.4 | 0..1 |
+---------------+---------+-------------+ +---------------+---------+-------------+
8.3.6. Usage Example 9.4.7. Usage Example
With the following type: With the following type:
type string { type string {
length "0..4"; length "0..4";
pattern "[0-9a-fA-F]*"; pattern "[0-9a-fA-F]*";
} }
the following strings match: the following strings match:
AB // legal AB // legal
9A00 // legal 9A00 // legal
and the following strings do not match: and the following strings do not match:
00ABAB // illegal 00ABAB // illegal
xx00 // illegal xx00 // illegal
skipping to change at page 97, line 14 skipping to change at page 111, line 46
the following strings match: the following strings match:
AB // legal AB // legal
9A00 // legal 9A00 // legal
and the following strings do not match: and the following strings do not match:
00ABAB // illegal 00ABAB // illegal
xx00 // illegal xx00 // illegal
8.4. The boolean Built-in Type 9.5. The boolean Built-in Type
The boolean built-in type represents a boolean value. The boolean built-in type represents a boolean value.
8.4.1. Lexicographic Representation 9.5.1. Lexicographic Representation
The lexicographical representation of a boolean value is the strings The lexicographical representation of a boolean value is the strings
"true" and "false". "true" and "false".
8.4.2. Restrictions 9.5.2. Restrictions
A boolean cannot be restricted. A boolean cannot be restricted.
8.5. The enumeration Built-in Type 9.6. The enumeration Built-in Type
The enumeration built-in type represents values from a set of The enumeration built-in type represents values from a set of
assigned names. assigned names.
8.5.1. Lexicographic Representation 9.6.1. Lexicographic Representation
The lexicographical representation of an enumeration value is the The lexicographical representation of an enumeration value is the
assigned name string. assigned name string.
8.5.2. Restrictions 9.6.2. Canonical Form
The canonical form is the assigned name string.
9.6.3. Restrictions
An enumeration cannot be restricted. An enumeration cannot be restricted.
8.5.3. The enum Statement 9.6.4. The enum Statement
The "enum" statement, which is a substatement to the "type" The "enum" statement, which is a substatement to the "type"
statement, MUST be present if the type is "enumeration". It is statement, MUST be present if the type is "enumeration". It is
repeatedly used to specify each assigned name of an enumeration type. repeatedly used to specify each assigned name of an enumeration type.
It takes as an argument a string which is the assigned name. It is It takes as an argument a string which is the assigned name. The
optionally followed by a block of substatements which holds detailed string MUST NOT be empty and MUST NOT have any leading or trailing
enum information. whitespace characters. The use of control codes SHOULD be avoided.
The statement is optionally followed by a block of substatements
which holds detailed enum information.
All assigned names in an enumeration MUST be unique. All assigned names in an enumeration MUST be unique.
8.5.3.1. The enum's Substatements 9.6.4.1. The enum's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| description | 7.17.3 | 0..1 | | description | 7.19.3 | 0..1 |
| reference | 7.17.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.17.2 | 0..1 | | status | 7.19.2 | 0..1 |
| value | 8.5.3.2 | 0..1 | | value | 9.6.4.2 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
8.5.3.2. The value Statement 9.6.4.2. The value Statement
The "value" statement, which is optional, is used to associate an The "value" statement, which is optional, is used to associate an
integer value with the assigned name for the enum. This integer integer value with the assigned name for the enum. This integer
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 sub-statement is the first one defined, the assigned If the enum sub-statement 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. the current highest enum 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 sub-statements following the one value MUST be specified for enum sub-statements following the one
with the current highest value. with the current highest value.
8.5.4. Usage Example 9.6.5. Usage Example
type enumeration { type enumeration {
enum enabled { enum enabled {
value 1; value 1;
} }
enum disabled { enum disabled {
value 2; value 2;
} }
} }
type enumeration { type enumeration {
enum zero; enum zero;
enum one; enum one;
enum seven { enum seven {
value 7; value 7;
} }
} }
8.6. 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.
8.6.1. Restrictions 9.7.1. Restrictions
A bits type cannot be restricted. A bits type cannot be restricted.
8.6.2. Lexicographic Representation 9.7.2. Lexicographic Representation
The lexicographical representation of the bits type is a space The lexicographical representation of the bits type is a space
separated list of the individual bit values that are set. An empty separated list of the individual bit values that are set. An empty
string thus represents a value where no bits are set. string thus represents a value where no bits are set.
8.6.3. The bit Statement 9.7.3. Canonical Form
In the canonical form, the bit values in the space separated list
appear in the same order as they are specified in the "bits"
statement.
9.7.4. The bit Statement
The "bit" statement, which is a substatement to the "type" statement, The "bit" statement, which is a substatement to the "type" statement,
MUST be present if the type is "bits". It is repeatedly used to MUST be present if the type is "bits". It is repeatedly used to
specify each assigned named bit of a bits type. It takes as an specify each assigned named bit of a bits type. It takes as an
argument a string which is the assigned name of the bit. It is argument a string which is the assigned name of the bit. It is
followed by a block of substatements which holds detailed bit followed by a block of substatements which holds detailed bit
information. A bit name follows the same syntax rules as an information. A bit name follows the same syntax rules as an
identifier (see Section 6.2). identifier (see Section 6.2).
All bit names in a bits type MUST be unique. All bit names in a bits type MUST be unique.
8.6.3.1. The bit's Substatements 9.7.4.1. The bit's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| description | 7.17.3 | 0..1 | | description | 7.19.3 | 0..1 |
| reference | 7.17.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.17.2 | 0..1 | | status | 7.19.2 | 0..1 |
| position | 8.6.3.2 | 0..1 | | position | 9.7.4.2 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
8.6.3.2. The position Statement 9.7.4.2. The position Statement
The "position" statement, which is optional, takes as an argument a The "position" statement, which is optional, takes as an argument a
non-negative integer value which specifies the bit's position within non-negative integer value which specifies the bit's position within
a hypothetical bit field. The position value MUST be in the range 0 a hypothetical bit field. The position value MUST be in the range 0
to 4294967295, and it MUST be unique within the bits type. The value to 4294967295, and it MUST be unique within the bits type. The value
is unused by YANG and the XML encoding, but is carried as a is unused by YANG and the XML encoding, but is carried as a
convenience to implementors. convenience to implementors.
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 sub-statement is the first one defined, the assigned. If the bit sub-statement 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. greater than the current highest bit 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 sub-statements then a position value MUST be specified for bit sub-statements
following the one with the current highest position value. following the one with the current highest position value.
8.6.4. Usage Example 9.7.5. Usage Example
Given the following type: Given the following type:
leaf mybits { leaf mybits {
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;
skipping to change at page 100, line 38 skipping to change at page 115, line 47
} }
} }
default "auto-sense-speed"; default "auto-sense-speed";
} }
The lexicographic representation of this leaf with bit values The lexicographic representation of this leaf with bit values
disable-nagle and 10-Mb-only set would be: disable-nagle and 10-Mb-only set would be:
<mybits>disable-nagle 10-Mb-only</mybits> <mybits>disable-nagle 10-Mb-only</mybits>
8.7. 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.
8.7.1. Restrictions 9.8.1. Restrictions
A binary can be restricted with the "length" (Section 8.3.3) A binary 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.
8.7.2. Lexicographic Representation 9.8.2. Lexicographic Representation
Binary values are encoded with the base64 encoding scheme [RFC4648]. Binary values are encoded with the base64 encoding scheme [RFC4648].
8.8. The keyref Built-in Type 9.8.3. Canonical Form
The canonical form of a binary value follow the rules in [RFC4648].
9.9. The keyref Built-in Type
The keyref type is used to reference a particular list entry in the The keyref type is used to reference a particular list entry in the
data tree. Its value is constrained to be the same as the key of an data tree. Its value is constrained to be the same as the key of an
existing list entry. existing list entry.
If the leaf with the keyref type represents configuration, the list If the leaf with the keyref type represents configuration data, the
entry it refers to MUST also represent configuration. Such a leaf list entry it refers to MUST also represent configuration. Such a
puts a constraint on a valid configuration. In a valid leaf puts a constraint on valid data. All keyref nodes MUST
configuration, all keyref nodes MUST reference existing list entries. reference existing list entries for the data to be valid. This
constraint is enforced according to the rules in Section 8.
8.8.1. Restrictions 9.9.1. Restrictions
A keyref cannot be restricted. A keyref cannot be restricted.
8.8.2. The path Statement 9.9.2. The path Statement
The "path" statement, which is a substatement to the "type" The "path" statement, which is a substatement to the "type"
statement, MUST be present if the type is "keyref". It takes as an statement, MUST be present if the type is "keyref". It takes as an
argument a string which MUST refer to one key node of a list entry. argument a string which MUST refer to one key node of a list entry.
The syntax for a path argument is a subset of the XPath syntax. It The syntax for a path argument is a subset of the XPath syntax. It
is an absolute or relative XPath location path in abbreviated syntax, is an absolute or relative XPath location path in abbreviated syntax,
where axes are not permitted, and predicates are used only for where axes are not permitted, and predicates are used only for
constraining the values for the key nodes for list entries. Each constraining the values for the key nodes for list entries. Each
predicate consists of at most one equality test per key. predicate consists of at most one equality test per key.
The predicates are only used when more than one key reference is The predicates are only used when more than one key reference is
needed to uniquely identify a list entry. This occurs if the list needed to uniquely identify a list entry. This occurs if the list
has multiple keys, or a reference to a list within a list is needed. has multiple keys, or a reference to a list within a list is needed.
In these cases, multiple keyref leafs are typically specified, and In these cases, multiple keyref leafs are typically specified, and
predicates are used to tie them together. predicates are used to tie them together.
The syntax is formally defined by the rule "path-arg" in Section 11. The syntax is formally defined by the rule "path-arg" in Section 12.
8.8.3. Lexicographic Representation 9.9.3. Lexicographic Representation
A keyref value is encoded the same way as the key it references. A keyref value is encoded the same way as the key it references.
8.8.4. Usage Example 9.9.4. Canonical Form
The canonical form of a keyref is the same as the canonical form of
the key it references.
9.9.5. Usage Example
With the following list: With the following list:
list interface { list interface {
key "name"; key "name";
leaf name { leaf name {
type string; type string;
} }
list address { list address {
key "ip"; key "ip";
skipping to change at page 103, line 27 skipping to change at page 118, line 42
<address> <address>
<ip>127.0.0.1</ip> <ip>127.0.0.1</ip>
</address> </address>
</interface> </interface>
<default-address> <default-address>
<ifname>eth0</ifname> <ifname>eth0</ifname>
<address>192.0.2.2</address> <address>192.0.2.2</address>
</default-address> </default-address>
8.9. The empty Built-in Type 9.10. The identityref Built-in Type
The identityref type is used to reference an existing identity (see
Section 7.16).
9.10.1. Restrictions
An identityref cannot be restricted.
9.10.2. The identityref's base Statement
The "base" statement, which is a substatement to the "type"
statement, MUST be present if the type is "identityref". The
argument is the name of an identity, as defined by an "identity"
statement. If a prefix is present on the identity name, it refers to
an identity defined the module which was imported with that prefix.
Otherwise an identity with the matching name must be defined in the
current module or an included submodule.
Valid values for an identityref are any identities derived from the
identityref's base identity.
9.10.3. Lexicographic Representation
An identityref is encoded as the referred identity's qualified name
[XML-NAMES].
[Editor's Note: TBD. How to handle prefixes?]
9.10.4. Usage Example
With the identity definitions in Section 7.16.3, the leaf:
import "crypto-base" {
prefix "crypto";
}
leaf crypto {
type identity-ref {
base "crypto:crypto-alg";
}
}
will be encoded as:
<crypto xmlns:des="http://example.com/des">des:des3</crypto>
Any prefixes used in the encoding are local to each instance
encoding. This means that the same identityref may be encoded
differently by different implementations. For example, the following
example encodes the same leaf as above:
<crypto xmlns:x="http://example.com/des">x:des3</crypto>
9.11. The empty Built-in Type
The empty built-in type represents a leaf that does not have any The empty built-in type represents a leaf that does not have any
value, it conveys information by its presence or absence. value, it conveys information by its presence or absence.
An empty type cannot have a default value. An empty type cannot have a default value.
8.9.1. Restrictions 9.11.1. Restrictions
An empty type cannot be restricted. An empty type cannot be restricted.
8.9.2. Lexicographic Representation 9.11.2. Lexicographic Representation
Not applicable. Not applicable.
8.9.3. Usage Example 9.11.3. Canonical Representation
Not applicable.
9.11.4. Usage Example
The following leaf The following leaf
leaf enable-qos { leaf enable-qos {
type empty; type empty;
} }
will be encoded as will be encoded as
<enable-qos/> <enable-qos/>
if it exists. if it exists.
8.10. The union Built-in Type 9.12. The union Built-in Type
The union built-in type represents a value that corresponds to one of The union built-in type represents a value that corresponds to one of
its member types. its member types.
When the type is "union", the "type" statement (Section 7.4) MUST be When the type is "union", the "type" statement (Section 7.4) MUST be
present. It is used to repeatedly specify each member type of the present. It is used to repeatedly specify each member type of the
union. It takes as an argument a string which is the name of a union. It takes as an argument a string which is the name of a
member type. member type.
A member type can be of any built-in or derived type, except it MUST A member type can be of any built-in or derived type, except it MUST
skipping to change at page 104, line 30 skipping to change at page 121, line 12
Example: Example:
type union { type union {
type int32; type int32;
type enumeration { type enumeration {
enum "unbounded"; enum "unbounded";
} }
} }
8.10.1. Restrictions 9.12.1. Restrictions
A union can not be restricted. However, each member type can be A union can not be restricted. However, each member type can be
restricted, based on the rules defined in Section 8 chapter. restricted, based on the rules defined in Section 9 chapter.
8.10.2. Lexicographic Representation 9.12.2. Lexicographic Representation
The lexicographical representation of an union is a value that The lexicographical representation of an union is a value that
corresponds to the representation of any one of the member types. corresponds to the representation of any one of the member types.
8.11. The instance-identifier Built-in Type 9.12.3. Canonical Form
The canonical form of a union value is the same as the canonical form
of the member type of the value.
9.13. The instance-identifier Built-in Type
The instance-identifier built-in type is used to uniquely identify a The instance-identifier built-in type is used to uniquely identify a
particular instance node in the data tree. particular instance node in the data tree.
The syntax for an instance-identifier is a subset of the XPath The syntax for an instance-identifier is a subset of the XPath
syntax, which is used to uniquely identify a node in the data tree. syntax, which is used to uniquely identify a node in the data tree.
It is an absolute XPath location path in abbreviated syntax, where It is an absolute XPath location path in abbreviated syntax, where
axes are not permitted, and predicates are used only for specifying axes are not permitted, and predicates are used only for specifying
the values for the key nodes for list entries, or a value of a leaf- the values for the key nodes for list entries, or a value of a leaf-
list. Each predicate consists of one equality test per key. Each list. Each predicate consists of one equality test per key. Each
key MUST have a corresponding predicate. key MUST have a corresponding predicate.
The syntax is formally defined by the rule "absolute-instid" in The syntax is formally defined by the rule "absolute-instid" in
Section 11. Section 12.
8.11.1. Restrictions 9.13.1. Restrictions
An instance-identifier cannot be restricted. An instance-identifier cannot be restricted.
8.11.2. Lexicographic Representation 9.13.2. Lexicographic Representation
An instance-identifier value is lexicographically represented as a An instance-identifier value is lexicographically represented as a
string in the XML encoding. The namespace prefixes used in the string in the XML encoding. The namespace prefixes used in the
encoding MUST be declared in the XML namespace scope in the instance- encoding MUST be declared in the XML namespace scope in the instance-
idenfitier's XML element. idenfitier's XML element.
Any prefixes used in the encoding are local to each instance Any prefixes used in the encoding are local to each instance
encoding. This means that the same instance-identifier may be encoding. This means that the same instance-identifier may be
encoded differently by different implementations. encoded differently by different implementations.
8.11.3. Usage Example 9.13.3. Canonical Form
[Editor's Note: TBD. How to handle prefixes?]
9.13.4. Usage Example
The following are examples of instance identifiers: The following are examples of instance identifiers:
/ex:system/ex:services/ex:ssh/ex:port /ex:system/ex:services/ex:ssh/ex:port
/ex:system/ex:user[ex:name='fred'] /ex:system/ex:user[ex:name='fred']
/ex:system/ex:user[ex:name='fred']/ex:type /ex:system/ex:user[ex:name='fred']/ex:type
/ex:system/ex:server[ex:ip='192.0.2.1'][ex:port='80'] /ex:system/ex:server[ex:ip='192.0.2.1'][ex:port='80']
/ex:system/ex:services/ex:ssh/ex:cipher[.='blowfish-cbc'] /ex:system/ex:services/ex:ssh/ex:cipher[.='blowfish-cbc']
9. Updating a Module 10. Updating a Module
[Editor's Note: add versioning rules, i.e. what can be done w/o As experience is gained with a module, it may be desirable to revise
changing the module name and the namespace] that module. However, changes are not allowed if they have any
potential to cause interoperability problems between a client using
an original specification and a server using an updated
specification.
10. YIN For any published change, a new "revision" statement (Section 7.1.9)
SHOULD be included in front of the existing revision statements.
Furthermore, any necessary changes MUST be applied to any meta
statements, including the "organization" and "contact" statements
(Section 7.1.7, Section 7.1.8).
Note that definitions contained in a module are available to be
imported by any other module, and are referenced in "import"
statements via the module name. Thus, a module name MUST NOT be
changed. Furthermore, the "namespace" statement MUST NOT be changed,
since all XML elements are encoded in the namespace.
Obsolete definitions MUST NOT be removed from modules since their
identifiers may still be referenced by other modules.
A definition may be revised in any of the following ways:
o An "enumeration" type may have new enums added, provided the old
enums's values do not change.
o A "bits" type may have new bits added, provided the old bits's
positions do not change.
o A "range", "length", or "pattern" statement may expand the allowed
value space.
o A "default" statement may be added.
o A "units" statement may be added.
o A "reference" statement may be added or updated.
o A "must" statement may be removed or its constraint relaxed.
o A "mandatory" statement may be removed or changed from "true" to
"false".
o A "min-elements" statement may be removed, or changed to require
less elements.
o A "max-elements" statement may be removed, or changed to allow
more elements.
o A "description" statement may be added or clarified without
changing the semantics of the definition.
o New typedefs, groupings, rpc, notifications, extensions, features,
and identities may be added.
o New data definition statements may be added if they do not add
mandatory nodes (Section 3.1) to existing nodes or at the top-
level in a module or submodule, or if they are conditionally
dependent on a new feature (i.e. have a "if-feature" statement
which refers to a new feature).
o A new "case" statement may be added.
o A node that represented state data may be changed to represent
configuration, provided it is not mandatory (Section 3.1).
o An "if-feature" statement may be removed, provided its node is not
mandatory (Section 3.1).
o A "status" statement may be added, or changed from "current" to
"deprecated" or "obsolete", or from "deprecated" to "obsolete".
o A "type" statement may be replaced with another "type" statement
which does not change the syntax or semantics of the type. For
example, an inline type definition may be replaced with a typedef,
but a int8 type cannot be replaced by a int16, since the syntax
would change.
o Any set of data definition nodes may be replaced with another set
of syntactically and semantically equivalent nodes. For example,
a set of leafs may be replaced by a uses of a grouping with the
same leafs.
o A module may be split into a set of submodules, or submodule may
be removed, provided the definitions in the module do not change
in any other way than allowed here.
o The "prefix" statment may be changed, provided all local uses of
the prefix also are changed.
Otherwise, if the semantics of any previous definition are changed
(i.e. if a non-editorial change is made to any definition other than
those specifically allowed above), then this MUST be achieved by a
new definition with a new identifier.
In statements which have any data definition statements as
substatements, those data definition substatements MUST NOT be
reordered.
[Editor's Note: These rules work as long as we have import/include by
revision]
11. YIN
A YANG module can be specified in an alternative XML-based syntax A YANG module can be specified in an alternative XML-based syntax
called YIN. This appendix describes symmetric mapping rules between called YIN. This section describes symmetric mapping rules between
the two formats. the two formats.
The YANG and YIN formats contain equivalent information using The YANG and YIN formats contain equivalent information using
different notations. The purpose of the YIN notation is to allow the different notations. The purpose of the YIN notation is to allow the
user to translate YANG into YIN, use the rich set of XML based tools user to translate YANG into YIN, use the rich set of XML based tools
on the YIN format to transform, or filter the model information. on the YIN format to transform, or filter the model information.
Tools like XSLT or XML validators can be utilized. After this the Tools like XSLT or XML validators can be utilized. After this the
model can be transformed back to the YANG format if needed, which model can be transformed back to the YANG format if needed, which
provides a more concise and readable format. provides a more concise and readable format.
The YANG-2-YIN and the YIN-2-YANG transformations will not modify the The YANG-2-YIN and the YIN-2-YANG transformations will not modify the
information content of the model. information content of the model.
10.1. Formal YIN Definition 11.1. Formal YIN Definition
YIN is described by an algorithm that transforms YANG to YIN. YIN is described by an algorithm that transforms YANG to YIN.
10.2. Transformation Algorithm YANG-2-YIN 11.2. Transformation Algorithm YANG-2-YIN
Every keyword results in a new XML element. The name of the element Every keyword results in a new XML element. The name of the element
is the keyword. All core YANG elements are defined in the namespace is the keyword. All core YANG elements are defined in the namespace
"urn:ietf:params:xml:ns:yang:yin:1". [XXX IANA] "urn:ietf:params:xml:ns:yang:yin:1". [XXX IANA]
The top-level element is always <module> or <submodule>. The top-level element is always <module> or <submodule>.
Elements which represent keywords that are imported extensions from Elements which represent keywords that are imported extensions from
other modules MUST be properly namespace qualified, where the other modules MUST be properly namespace qualified, where the
namespace is the namespace of the imported module. Translators namespace is the namespace of the imported module. The XML prefix
SHOULD use the same prefix as used in the YANG module. for such extensions MUST be the same as the prefix defined in the
module's "import" statement.
Elements which represent keywords that are included extensions from
other submodules MUST be properly namespace qualified, where the
namespace is the namespace of the module that the submodule belongs
to. The XML prefix for such extensions MUST be the same as the local
prefix, i.e. for a module it is as defined in the "prefix" statement,
and for a submodule, as defined in the submodule's "belongs-to"
statement.
If the keyword has an argument, its encoding depends on the value of If the keyword has an argument, its encoding depends on the value of
the argument's "yin-element". If "yin-element" is false, the the argument's "yin-element". If "yin-element" is false, the
argument is encoded as an XML attribute to the keyword's element. If argument is encoded as an XML attribute to the keyword's element. If
"yin-element" is true, the argument is encoded as a subelement to the "yin-element" is true, the argument is encoded as a subelement to the
keyword's element. The name of the attribute or element is the name keyword's element. The name of the attribute or element is the name
of the argument. of the argument.
The core YANG keywords have arguments according to the table below. The core YANG keywords have arguments according to the table below.
Extension keywords have arguments according to Section 7.16.2. Extension keywords have arguments according to Section 7.17.2.
YANG to YIN keyword map YANG to YIN keyword map
+---------------+---------------+-------------+ +---------------+---------------+-------------+
| keyword | argument name | yin-element | | keyword | argument name | yin-element |
+---------------+---------------+-------------+ +---------------+---------------+-------------+
| anyxml | name | false | | anyxml | name | false |
| argument | name | false | | argument | name | false |
| augment | target-node | false | | augment | target-node | false |
| base | name | false |
| belongs-to | module | false | | belongs-to | module | false |
| bit | name | false | | bit | name | false |
| case | name | false | | case | name | false |
| choice | name | false | | choice | name | false |
| config | value | false | | config | value | false |
| contact | info | true | | contact | info | true |
| container | name | false | | container | name | false |
| default | value | false | | default | value | false |
| description | text | true | | description | text | true |
| enum | name | false | | enum | name | false |
| error-app-tag | value | false | | error-app-tag | value | false |
| error-message | value | true | | error-message | value | true |
| extension | name | false | | extension | name | false |
| deviate | target-node | false |
| deviation | value | false |
| feature | name | false |
| grouping | name | false | | grouping | name | false |
| identity | name | false |
| if-feature | name | false |
| import | module | false | | import | module | false |
| include | module | false | | include | module | false |
| input | <no argument> | n/a | | input | <no argument> | n/a |
| key | value | false | | key | value | false |
| leaf | name | false | | leaf | name | false |
| leaf-list | name | false | | leaf-list | name | false |
| length | value | false | | length | value | false |
| list | name | false | | list | name | false |
| mandatory | value | false | | mandatory | value | false |
| max-elements | value | false | | max-elements | value | false |
skipping to change at page 108, line 49 skipping to change at page 128, line 14
| ordered-by | value | false | | ordered-by | value | false |
| organization | info | true | | organization | info | true |
| output | <no argument> | n/a | | output | <no argument> | n/a |
| path | value | false | | path | value | false |
| pattern | value | false | | pattern | value | false |
| position | value | false | | position | value | false |
| prefix | value | false | | prefix | value | false |
| presence | value | false | | presence | value | false |
| range | value | false | | range | value | false |
| reference | info | false | | reference | info | false |
| refine | target-node | false |
| revision | date | false | | revision | date | false |
| rpc | name | false | | rpc | name | false |
| status | value | false | | status | value | false |
| submodule | name | false | | submodule | name | false |
| type | name | false | | type | name | false |
| typedef | name | false | | typedef | name | false |
| unique | tag | false | | unique | tag | false |
| units | name | false | | units | name | false |
| uses | name | false | | uses | name | false |
| value | value | false | | value | value | false |
| when | condition | false | | when | condition | false |
| yang-version | value | false | | yang-version | value | false |
| yin-element | value | false | | yin-element | value | false |
+---------------+---------------+-------------+ +---------------+---------------+-------------+
Table 30 Table 35
If a statement is followed by substatements, those substatements are If a statement is followed by substatements, those substatements are
subelements in the YIN mapping. subelements in the YIN mapping.
Comments in YANG MAY be transformed into XML comments. Comments in YANG MAY be transformed into XML comments.
10.2.1. Usage Example 11.2.1. Usage Example
The following YANG snippet: The following YANG snippet:
leaf mtu { leaf mtu {
type uint32; type uint32;
description "The MTU of the interface."; description "The MTU of the interface.";
} }
is translated into the following YIN snippet: is translated into the following YIN snippet:
<leaf name="mtu"> <leaf name="mtu">
<type name="uint32"/> <type name="uint32"/>
<description> <description>
<text>The MTU of the interface."</text> <text>The MTU of the interface."</text>
</description> </description>
</leaf> </leaf>
10.3. Transformation Algorithm YIN-2-YANG 11.3. Transformation Algorithm YIN-2-YANG
The transformation is based on a recursive algorithm that is started The transformation is based on a recursive algorithm that is started
on the <module> or <submodule> element. on the <module> or <submodule> element.
The element is transformed into a YANG keyword. If the keyword in The element is transformed into a YANG keyword. If the keyword in
Table 30 is marked as yin-element true, the subelement with the Table 35 is marked as yin-element true, the subelement with the
keyword's argument name in Table 30 contains the YANG keyword's keyword's argument name in Table 35 contains the YANG keyword's
argument as text content. If the keyword in Table 30 is marked as argument as text content. If the keyword in Table 35 is marked as
yin-element false, the element's attribute with keyword's argument yin-element false, the element's attribute with keyword's argument
name in Table 30 contains the YANG keyword's argument. name in Table 35 contains the YANG keyword's argument.
If there are no other subelements to the element, the YANG statement If there are no other subelements to the element, the YANG statement
is closed with a ";". Otherwise, each such subelement is is closed with a ";". Otherwise, each such subelement is
transformed, according to the same algorithm, as substatements to the transformed, according to the same algorithm, as substatements to the
current YANG statement, enclosed within "{" and "}". current YANG statement, enclosed within "{" and "}".
XML comments in YIN MAY be transformed into YANG comments. XML comments in YIN MAY be transformed into YANG comments.
10.3.1. Tabulation, Formatting 11.3.1. Tabulation, Formatting
To get a readable YANG module the YANG output will have to be To get a readable YANG module the YANG output will have to be
indented with appropriate whitespace characters. indented with appropriate whitespace characters.
11. YANG ABNF Grammar 12. YANG ABNF Grammar
In YANG, almost all statements are unordered. The ABNF grammar In YANG, almost all statements are unordered. The ABNF grammar
[RFC5234] defines the canonical order. To improve module [RFC5234] defines the canonical order. To improve module
readability, it is RECOMMENDED that clauses be entered in this order. readability, it is RECOMMENDED that clauses be entered in this order.
Within the ABNF grammar, unordered statements are marked with Within the ABNF grammar, unordered statements are marked with
comments. comments.
This grammar assumes that the scanner replaces YANG comments with a This grammar assumes that the scanner replaces YANG comments with a
single space character. single space character.
skipping to change at page 112, line 10 skipping to change at page 131, line 10
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
linkage-stmts = ;; these stmts can appear in any order linkage-stmts = ;; these stmts can appear in any order
*(import-stmt stmtsep) *(import-stmt stmtsep)
*(include-stmt stmtsep) *(include-stmt stmtsep)
revision-stmts = *(revision-stmt stmtsep) revision-stmts = *(revision-stmt stmtsep)
body-stmts = *((extension-stmt / body-stmts = *((extension-stmt /
feature-stmt /
identity-stmt /
typedef-stmt / typedef-stmt /
grouping-stmt / grouping-stmt /
data-def-stmt / data-def-stmt /
augment-stmt /
rpc-stmt / rpc-stmt /
notification-stmt) stmtsep) notification-stmt /
deviation-stmt) stmtsep)
data-def-stmt = container-stmt / data-def-stmt = container-stmt /
leaf-stmt / leaf-stmt /
leaf-list-stmt / leaf-list-stmt /
list-stmt / list-stmt /
choice-stmt / choice-stmt /
anyxml-stmt / anyxml-stmt /
uses-stmt / uses-stmt /
augment-stmt
case-data-def-stmt = container-stmt / case-data-def-stmt = container-stmt /
leaf-stmt / leaf-stmt /
leaf-list-stmt / leaf-list-stmt /
list-stmt / list-stmt /
anyxml-stmt / anyxml-stmt /
uses-stmt / uses-stmt
augment-stmt
yang-version-stmt = yang-version-keyword sep yang-version-arg-str yang-version-stmt = yang-version-keyword sep yang-version-arg-str
optsep stmtend optsep stmtend
yang-version-arg-str = < a string which matches the rule yang-version-arg-str = < a string which matches the rule
yang-version-arg > yang-version-arg >
yang-version-arg = "1" yang-version-arg = "1"
import-stmt = import-keyword sep identifier-arg-str optsep import-stmt = import-keyword sep identifier-arg-str optsep
skipping to change at page 113, line 10 skipping to change at page 132, line 12
namespace-stmt = namespace-keyword sep uri-str optsep stmtend namespace-stmt = namespace-keyword sep uri-str optsep stmtend
uri-str = < a string which matches the rule uri-str = < a string which matches the rule
URI in RFC 3986 > URI in RFC 3986 >
prefix-stmt = prefix-keyword sep prefix-arg-str prefix-stmt = prefix-keyword sep prefix-arg-str
optsep stmtend optsep stmtend
belongs-to-stmt = belongs-to-keyword sep identifier-arg-str belongs-to-stmt = belongs-to-keyword sep identifier-arg-str
optsep stmtend optsep
"{" stmtsep
prefix-stmt stmtsep
"}"
organization-stmt = organization-keyword sep string organization-stmt = organization-keyword sep string
optsep stmtend optsep stmtend
contact-stmt = contact-keyword sep string optsep stmtend contact-stmt = contact-keyword sep string optsep stmtend
description-stmt = description-keyword sep string optsep description-stmt = description-keyword sep string optsep
stmtend stmtend
reference-stmt = reference-keyword sep string optsep stmtend reference-stmt = reference-keyword sep string optsep stmtend
skipping to change at page 114, line 7 skipping to change at page 133, line 10
"}") "}")
yin-element-stmt = yin-element-keyword sep yin-element-arg-str yin-element-stmt = yin-element-keyword sep yin-element-arg-str
stmtend stmtend
yin-element-arg-str = < a string which matches the rule yin-element-arg-str = < a string which matches the rule
yin-element-arg > yin-element-arg >
yin-element-arg = true-keyword / false-keyword yin-element-arg = true-keyword / false-keyword
identity-stmt = identity-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[base-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")
base-stmt = base-keyword sep identifier-ref-arg-str
optsep stmtend
feature-stmt = feature-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
*(if-feature-stmt stmtsep)
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")
if-feature-stmt = if-feature-keyword sep identifier-ref-arg-str
optsep stmtend
typedef-stmt = typedef-keyword sep identifier-arg-str optsep typedef-stmt = typedef-keyword sep identifier-arg-str optsep
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
type-stmt stmtsep type-stmt stmtsep
[units-stmt stmtsep] [units-stmt stmtsep]
[default-stmt stmtsep] [default-stmt stmtsep]
[status-stmt stmtsep] [status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
"}" "}"
type-stmt = type-keyword sep identifier-ref-arg-str optsep type-stmt = type-keyword sep identifier-ref-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
( numerical-restrictions / type-body-stmts
"}")
type-body-stmts = numerical-restrictions /
string-restrictions / string-restrictions /
enum-specification / enum-specification /
keyref-specification / keyref-specification /
identityref-specification /
bits-specification / bits-specification /
union-specification ) union-specification
stmtsep
"}")
numerical-restrictions = range-stmt stmtsep numerical-restrictions = range-stmt stmtsep
range-stmt = range-keyword sep range-arg-str optsep range-stmt = range-keyword sep range-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[error-message-stmt stmtsep] [error-message-stmt stmtsep]
[error-app-tag-stmt stmtsep] [error-app-tag-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
skipping to change at page 115, line 21 skipping to change at page 135, line 5
[error-message-stmt stmtsep] [error-message-stmt stmtsep]
[error-app-tag-stmt stmtsep] [error-app-tag-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
"}") "}")
default-stmt = default-keyword sep string stmtend default-stmt = default-keyword sep string stmtend
enum-specification = 1*(enum-stmt stmtsep) enum-specification = 1*(enum-stmt stmtsep)
enum-stmt = enum-keyword sep identifier-arg-str optsep enum-stmt = enum-keyword sep string optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[value-stmt stmtsep] [value-stmt stmtsep]
[status-stmt stmtsep] [status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
"}") "}")
keyref-specification = path-stmt stmtsep keyref-specification = path-stmt stmtsep
path-stmt = path-keyword sep path-arg-str stmtend path-stmt = path-keyword sep path-arg-str stmtend
identityref-specification = base-stmt stmtsep
union-specification = 1*(type-stmt stmtsep) union-specification = 1*(type-stmt stmtsep)
bits-specification = 1*(bit-stmt stmtsep) bits-specification = 1*(bit-stmt stmtsep)
bit-stmt = bit-keyword sep identifier-arg-str optsep bit-stmt = bit-keyword sep identifier-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[position-stmt stmtsep] [position-stmt stmtsep]
[status-stmt stmtsep] [status-stmt stmtsep]
skipping to change at page 117, line 45 skipping to change at page 137, line 32
[reference-stmt stmtsep] [reference-stmt stmtsep]
*((typedef-stmt / *((typedef-stmt /
grouping-stmt) stmtsep) grouping-stmt) stmtsep)
*(data-def-stmt stmtsep) *(data-def-stmt stmtsep)
"}") "}")
container-stmt = container-keyword sep identifier-arg-str optsep container-stmt = container-keyword sep identifier-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
*(must-stmt stmtsep) *(must-stmt stmtsep)
[presence-stmt stmtsep] [presence-stmt stmtsep]
[config-stmt stmtsep] [config-stmt stmtsep]
[status-stmt stmtsep] [status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
*((typedef-stmt / *((typedef-stmt /
grouping-stmt) stmtsep) grouping-stmt) stmtsep)
*(data-def-stmt stmtsep) *(data-def-stmt stmtsep)
"}") "}")
leaf-stmt = leaf-keyword sep identifier-arg-str optsep leaf-stmt = leaf-keyword sep identifier-arg-str optsep
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
type-stmt stmtsep type-stmt stmtsep
[units-stmt stmtsep] [units-stmt stmtsep]
*(must-stmt stmtsep) *(must-stmt stmtsep)
[default-stmt stmtsep] [default-stmt stmtsep]
[config-stmt stmtsep] [config-stmt stmtsep]
[mandatory-stmt stmtsep] [mandatory-stmt stmtsep]
[status-stmt stmtsep] [status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
"}" "}"
leaf-list-stmt = leaf-list-keyword sep identifier-arg-str optsep leaf-list-stmt = leaf-list-keyword sep identifier-arg-str optsep
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
type-stmt stmtsep type-stmt stmtsep
[units-stmt stmtsep] [units-stmt stmtsep]
*(must-stmt stmtsep) *(must-stmt stmtsep)
[config-stmt stmtsep] [config-stmt stmtsep]
[min-elements-stmt stmtsep] [min-elements-stmt stmtsep]
[max-elements-stmt stmtsep] [max-elements-stmt stmtsep]
[ordered-by-stmt stmtsep] [ordered-by-stmt stmtsep]
[status-stmt stmtsep] [status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
"}" "}"
list-stmt = list-keyword sep identifier-arg-str optsep list-stmt = list-keyword sep identifier-arg-str optsep
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
*(must-stmt stmtsep) *(must-stmt stmtsep)
[key-stmt stmtsep] [key-stmt stmtsep]
*(unique-stmt stmtsep) *(unique-stmt stmtsep)
[config-stmt stmtsep] [config-stmt stmtsep]
[min-elements-stmt stmtsep] [min-elements-stmt stmtsep]
[max-elements-stmt stmtsep] [max-elements-stmt stmtsep]
[ordered-by-stmt stmtsep] [ordered-by-stmt stmtsep]
[status-stmt stmtsep] [status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
skipping to change at page 119, line 26 skipping to change at page 139, line 20
unique-arg-str = < a string which matches the rule unique-arg-str = < a string which matches the rule
unique-arg > unique-arg >
unique-arg = descendant-schema-nodeid unique-arg = descendant-schema-nodeid
*(sep descendant-schema-nodeid) *(sep descendant-schema-nodeid)
choice-stmt = choice-keyword sep identifier-arg-str optsep choice-stmt = choice-keyword sep identifier-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
[default-stmt stmtsep] [default-stmt stmtsep]
[config-stmt stmtsep] [config-stmt stmtsep]
[mandatory-stmt stmtsep] [mandatory-stmt stmtsep]
[status-stmt stmtsep] [status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
*((short-case-stmt / case-stmt) stmtsep) *((short-case-stmt / case-stmt) stmtsep)
"}") "}")
short-case-stmt = container-stmt / short-case-stmt = container-stmt /
leaf-stmt / leaf-stmt /
leaf-list-stmt / leaf-list-stmt /
list-stmt / list-stmt /
anyxml-stmt anyxml-stmt
case-stmt = case-keyword sep identifier-arg-str optsep case-stmt = case-keyword sep identifier-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
[status-stmt stmtsep] [status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
*(case-data-def-stmt stmtsep) *(case-data-def-stmt stmtsep)
"}") "}")
anyxml-stmt = anyxml-keyword sep identifier-arg-str optsep anyxml-stmt = anyxml-keyword sep identifier-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
[config-stmt stmtsep] [config-stmt stmtsep]
[mandatory-stmt stmtsep] [mandatory-stmt stmtsep]
[status-stmt stmtsep] [status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
"}") "}")
uses-stmt = uses-keyword sep identifier-ref-arg-str optsep uses-stmt = uses-keyword sep identifier-ref-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
[status-stmt stmtsep] [status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
*(refinement-stmt stmtsep) *(refinement-stmt stmtsep)
*(uses-augment-stmt stmtsep)
"}") "}")
refinement-stmt = refine-container-stmt / refinement-stmt = refine-keyword sep refine-arg-str optsep
refine-leaf-stmt /
refine-leaf-list-stmt /
refine-list-stmt /
refine-choice-stmt /
refine-anyxml-stmt
refine-leaf-stmt = leaf-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order (refine-container-stmts /
refine-leaf-stmts /
refine-leaf-list-stmts /
refine-list-stmts /
refine-choice-stmts /
refine-case-stmts /
refine-anyxml-stmts)
"}"
refine-arg-str = < a string which matches the rule
refine-arg >
refine-arg = descendant-schema-nodeid
refine-container-stmts = ;; these stmts can appear in any order
*(must-stmt stmtsep)
[presence-stmt stmtsep]
[config-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
refine-leaf-stmts = ;; these stmts can appear in any order
*(must-stmt stmtsep) *(must-stmt stmtsep)
[default-stmt stmtsep] [default-stmt stmtsep]
[config-stmt stmtsep] [config-stmt stmtsep]
[mandatory-stmt stmtsep] [mandatory-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
"}")
refine-leaf-list-stmt = leaf-list-keyword sep identifier-arg-str optsep refine-leaf-list-stmts = ;; these stmts can appear in any order
(";" /
"{" stmtsep
;; these stmts can appear in any order
*(must-stmt stmtsep) *(must-stmt stmtsep)
[config-stmt stmtsep] [config-stmt stmtsep]
[min-elements-stmt stmtsep] [min-elements-stmt stmtsep]
[max-elements-stmt stmtsep] [max-elements-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
"}")
refine-list-stmt = list-keyword sep identifier-arg-str optsep refine-list-stmts = ;; these stmts can appear in any order
(";" /
"{" stmtsep
;; these stmts can appear in any order
*(must-stmt stmtsep) *(must-stmt stmtsep)
[config-stmt stmtsep] [config-stmt stmtsep]
[min-elements-stmt stmtsep] [min-elements-stmt stmtsep]
[max-elements-stmt stmtsep] [max-elements-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
*(refinement-stmt stmtsep)
"}")
refine-choice-stmt = choice-keyword sep identifier-arg-str optsep refine-choice-stmts = ;; these stmts can appear in any order
(";" /
"{" stmtsep
;; these stmts can appear in any order
[default-stmt stmtsep] [default-stmt stmtsep]
[mandatory-stmt stmtsep] [mandatory-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
*(refine-case-stmt stmtsep)
"}")
refine-case-stmt = case-keyword sep identifier-arg-str optsep refine-case-stmts = ;; these stmts can appear in any order
(";" /
"{" stmtsep
;; these stmts can appear in any order
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
*(refinement-stmt stmtsep)
"}")
refine-container-stmt = container-keyword sep identifier-arg-str optsep refine-anyxml-stmts = ;; these stmts can appear in any order
(";" /
"{" stmtsep
;; these stmts can appear in any order
*(must-stmt stmtsep)
[presence-stmt stmtsep]
[config-stmt stmtsep] [config-stmt stmtsep]
[mandatory-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
*(refinement-stmt stmtsep)
"}")
refine-anyxml-stmt = anyxml-keyword sep identifier-arg-str optsep uses-augment-stmt = augment-keyword sep uses-augment-arg-str optsep
(";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[config-stmt stmtsep] [when-stmt stmtsep]
[mandatory-stmt stmtsep] *(if-feature-stmt stmtsep)
[status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
"}") 1*((data-def-stmt stmtsep) /
(case-stmt stmtsep))
"}"
unknown-statement = prefix ":" identifier [sep string] optsep uses-augment-arg-str = < a string which matches the rule
(";" / "{" *unknown-statement "}") uses-augment-arg >
uses-augment-arg = descendant-schema-nodeid
augment-stmt = augment-keyword sep augment-arg-str optsep augment-stmt = augment-keyword sep augment-arg-str optsep
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[when-stmt stmtsep] [when-stmt stmtsep]
*(if-feature-stmt stmtsep)
[status-stmt stmtsep] [status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
1*((data-def-stmt stmtsep) / 1*((data-def-stmt stmtsep) /
(case-stmt stmtsep)) (case-stmt stmtsep))
"}" "}"
augment-arg-str = < a string which matches the rule augment-arg-str = < a string which matches the rule
augment-arg > augment-arg >
augment-arg = absolute-schema-nodeid / augment-arg = absolute-schema-nodeid
descendant-schema-nodeid
unknown-statement = prefix ":" identifier [sep string] optsep
(";" / "{" *unknown-statement "}")
when-stmt = when-keyword sep string stmtend when-stmt = when-keyword sep string stmtend
rpc-stmt = rpc-keyword sep identifier-arg-str optsep rpc-stmt = rpc-keyword sep identifier-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
*(if-feature-stmt stmtsep)
[status-stmt stmtsep] [status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
*((typedef-stmt / *((typedef-stmt /
grouping-stmt) stmtsep) grouping-stmt) stmtsep)
[input-stmt stmtsep] [input-stmt stmtsep]
[output-stmt stmtsep] [output-stmt stmtsep]
"}") "}")
input-stmt = input-keyword optsep input-stmt = input-keyword optsep
skipping to change at page 123, line 22 skipping to change at page 143, line 22
*((typedef-stmt / *((typedef-stmt /
grouping-stmt) stmtsep) grouping-stmt) stmtsep)
1*(data-def-stmt stmtsep) 1*(data-def-stmt stmtsep)
"}" "}"
notification-stmt = notification-keyword sep notification-stmt = notification-keyword sep
identifier-arg-str optsep identifier-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
*(if-feature-stmt stmtsep)
[status-stmt stmtsep] [status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
*((typedef-stmt / *((typedef-stmt /
grouping-stmt) stmtsep) grouping-stmt) stmtsep)
*(data-def-stmt stmtsep) *(data-def-stmt stmtsep)
"}") "}")
deviation-stmt = deviation-keyword sep
deviation-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[description-stmt stmtsep]
[reference-stmt stmtsep]
*(deviate-stmt stmtsep)
"}"
deviation-arg-str = < a string which matches the rule
deviation-arg >
deviation-arg = absolute-schema-nodeid
deviate-stmt = deviate-keyword sep deviate-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[type-stmt stmtsep]
[units-stmt stmtsep]
*(must-stmt stmtsep)
*(unique-stmt stmtsep)
[default-stmt stmtsep]
[config-stmt stmtsep]
[mandatory-stmt stmtsep]
[min-elements-stmt stmtsep]
[max-elements-stmt stmtsep]
"}"
deviate-arg-str = < a string which matches the rule
deviate-arg >
deviate-arg = add-keyword /
delete-keyword /
replace-keyword /
not-supported-keyword
;; Ranges ;; Ranges
range-arg-str = < a string which matches the rule range-arg-str = < a string which matches the rule
range-arg > range-arg >
range-arg = range-part *(optsep "|" optsep range-part) range-arg = range-part *(optsep "|" optsep range-part)
range-part = range-boundary range-part = range-boundary
[optsep ".." optsep range-boundary] [optsep ".." optsep range-boundary]
skipping to change at page 125, line 31 skipping to change at page 146, line 20
(".." "/" (".." "/"
*relative-path) *relative-path)
descendant-path = node-identifier *path-predicate descendant-path = node-identifier *path-predicate
absolute-path absolute-path
path-predicate = "[" *WSP path-equality-expr *WSP "]" path-predicate = "[" *WSP path-equality-expr *WSP "]"
path-equality-expr = node-identifier *WSP "=" *WSP path-key-expr path-equality-expr = node-identifier *WSP "=" *WSP path-key-expr
path-key-expr = this-variable-keyword "/" rel-path-keyexpr path-key-expr = current-function-invocation "/"
rel-path-keyexpr
rel-path-keyexpr = 1*(".." "/") *(node-identifier "/") rel-path-keyexpr = 1*(".." "/") *(node-identifier "/")
node-identifier node-identifier
;;; Keywords, using abnfgen's syntax for case-sensitive strings ;;; Keywords, using abnfgen's syntax for case-sensitive strings
;; statment keywords ;; statment keywords
anyxml-keyword = 'anyxml' anyxml-keyword = 'anyxml'
argument-keyword = 'argument' argument-keyword = 'argument'
augment-keyword = 'augment' augment-keyword = 'augment'
base-keyword = 'base'
belongs-to-keyword = 'belongs-to' belongs-to-keyword = 'belongs-to'
bit-keyword = 'bit' bit-keyword = 'bit'
case-keyword = 'case' case-keyword = 'case'
choice-keyword = 'choice' choice-keyword = 'choice'
config-keyword = 'config' config-keyword = 'config'
contact-keyword = 'contact' contact-keyword = 'contact'
container-keyword = 'container' container-keyword = 'container'
default-keyword = 'default' default-keyword = 'default'
description-keyword = 'description' description-keyword = 'description'
enum-keyword = 'enum' enum-keyword = 'enum'
skipping to change at page 126, line 4 skipping to change at page 146, line 44
bit-keyword = 'bit' bit-keyword = 'bit'
case-keyword = 'case' case-keyword = 'case'
choice-keyword = 'choice' choice-keyword = 'choice'
config-keyword = 'config' config-keyword = 'config'
contact-keyword = 'contact' contact-keyword = 'contact'
container-keyword = 'container' container-keyword = 'container'
default-keyword = 'default' default-keyword = 'default'
description-keyword = 'description' description-keyword = 'description'
enum-keyword = 'enum' enum-keyword = 'enum'
error-app-tag-keyword = 'error-app-tag' error-app-tag-keyword = 'error-app-tag'
error-message-keyword = 'error-message' error-message-keyword = 'error-message'
extension-keyword = 'extension' extension-keyword = 'extension'
deviation-keyword = 'deviation'
deviate-keyword = 'deviate'
feature-keyword = 'feature'
grouping-keyword = 'grouping' grouping-keyword = 'grouping'
identity-keyword = 'identity'
if-feature-keyword = 'if-feature'
import-keyword = 'import' import-keyword = 'import'
include-keyword = 'include' include-keyword = 'include'
input-keyword = 'input' input-keyword = 'input'
key-keyword = 'key' key-keyword = 'key'
leaf-keyword = 'leaf' leaf-keyword = 'leaf'
leaf-list-keyword = 'leaf-list' leaf-list-keyword = 'leaf-list'
length-keyword = 'length' length-keyword = 'length'
list-keyword = 'list' list-keyword = 'list'
mandatory-keyword = 'mandatory' mandatory-keyword = 'mandatory'
max-elements-keyword = 'max-elements' max-elements-keyword = 'max-elements'
min-elements-keyword = 'min-elements' min-elements-keyword = 'min-elements'
skipping to change at page 126, line 33 skipping to change at page 147, line 29
ordered-by-keyword = 'ordered-by' ordered-by-keyword = 'ordered-by'
organization-keyword = 'organization' organization-keyword = 'organization'
output-keyword = 'output' output-keyword = 'output'
path-keyword = 'path' path-keyword = 'path'
pattern-keyword = 'pattern' pattern-keyword = 'pattern'
position-keyword = 'position' position-keyword = 'position'
prefix-keyword = 'prefix' prefix-keyword = 'prefix'
presence-keyword = 'presence' presence-keyword = 'presence'
range-keyword = 'range' range-keyword = 'range'
reference-keyword = 'reference' reference-keyword = 'reference'
refine-keyword = 'refine'
revision-keyword = 'revision' revision-keyword = 'revision'
rpc-keyword = 'rpc' rpc-keyword = 'rpc'
status-keyword = 'status' status-keyword = 'status'
submodule-keyword = 'submodule' submodule-keyword = 'submodule'
type-keyword = 'type' type-keyword = 'type'
typedef-keyword = 'typedef' typedef-keyword = 'typedef'
unique-keyword = 'unique' unique-keyword = 'unique'
units-keyword = 'units' units-keyword = 'units'
uses-keyword = 'uses' uses-keyword = 'uses'
value-keyword = 'value' value-keyword = 'value'
when-keyword = 'when' when-keyword = 'when'
yang-version-keyword = 'yang-version' yang-version-keyword = 'yang-version'
yin-element-keyword = 'yin-element' yin-element-keyword = 'yin-element'
;; other keywords ;; other keywords
add-keyword = 'add'
current-keyword = 'current' current-keyword = 'current'
delete-keyword = 'delete'
deprecated-keyword = 'deprecated' deprecated-keyword = 'deprecated'
false-keyword = 'false' false-keyword = 'false'
max-keyword = 'max' max-keyword = 'max'
min-keyword = 'min' min-keyword = 'min'
nan-keyword = 'NaN' nan-keyword = 'NaN'
neginf-keyword = '-INF' neginf-keyword = '-INF'
not-supported-keyword = 'not-supported'
obsolete-keyword = 'obsolete' obsolete-keyword = 'obsolete'
posinf-keyword = 'INF' posinf-keyword = 'INF'
replace-keyword = 'replace'
system-keyword = 'system' system-keyword = 'system'
this-variable-keyword = '$this'
true-keyword = 'true' true-keyword = 'true'
unbounded-keyword = 'unbounded' unbounded-keyword = 'unbounded'
user-keyword = 'user' user-keyword = 'user'
current-function-invocation = 'current()'
;; Basic Rules ;; Basic Rules
keyword = [prefix ":"] identifier keyword = [prefix ":"] identifier
prefix-arg-str = < a string which matches the rule prefix-arg-str = < a string which matches the rule
prefix-arg > prefix-arg >
prefix-arg = prefix prefix-arg = prefix
prefix = identifier prefix = identifier
skipping to change at page 130, line 5 skipping to change at page 151, line 5
SP = %x20 SP = %x20
; space ; space
VCHAR = %x21-7E VCHAR = %x21-7E
; visible (printing) characters ; visible (printing) characters
WSP = SP / HTAB WSP = SP / HTAB
; white space ; white space
12. Error Responses for YANG Related Errors 13. Error Responses for YANG Related Errors
A number of NETCONF error responses are defined for error cases A number of NETCONF error responses are defined for error cases
related to the data-model handling. If the relevant YANG statement related to the data-model handling. If the relevant YANG statement
has an "error-app-tag" substatement, that overrides the default value has an "error-app-tag" substatement, that overrides the default value
specified below. specified below.
12.1. Error Message for Data that Violates a YANG unique Statement: 13.1. Error Message for Data that Violates a YANG unique Statement:
If a NETCONF operation would result in configuration data where a If a NETCONF operation would result in configuration data where a
unique constraint is invalidated, the following error is returned: unique constraint is invalidated, the following error is returned:
Tag: operation-failed Tag: operation-failed
Error-app-tag: data-not-unique Error-app-tag: data-not-unique
Error-info: <non-unique>: Contains an instance identifier which Error-info: <non-unique>: Contains an instance identifier which
points to a leaf which invalidates the unique points to a leaf which invalidates the unique
constraint. This element is present once for each constraint. This element is present once for each
leaf invalidating the unique constraint. leaf invalidating the unique constraint.
The <non-unique> element is in the YANG The <non-unique> element is in the YANG
namespace ("urn:ietf:params:xml:ns:yang:1" namespace ("urn:ietf:params:xml:ns:yang:1"
[XXX IANA]). [XXX IANA]).
12.2. Error Message for Data that Violates a YANG max-elements 13.2. Error Message for Data that Violates a YANG max-elements
Statement: Statement:
If a NETCONF operation would result in configuration data where a If a NETCONF operation would result in configuration data where a
list or a leaf-list would have too many entries the following error list or a leaf-list would have too many entries the following error
is returned: is returned:
Tag: operation-failed Tag: operation-failed
Error-app-tag: too-many-elements Error-app-tag: too-many-elements
This error is returned once, with the error-path identifying the list This error is returned once, with the error-path identifying the list
node, even if there are more than one extra child present. node, even if there are more than one extra child present.
12.3. Error Message for Data that Violates a YANG min-elements 13.3. Error Message for Data that Violates a YANG min-elements
Statement: Statement:
If a NETCONF operation would result in configuration data where a If a NETCONF operation would result in configuration data where a
list or a leaf-list would have too few entries the following error is list or a leaf-list would have too few entries the following error is
returned: returned:
Tag: operation-failed Tag: operation-failed
Error-app-tag: too-few-elements Error-app-tag: too-few-elements
This error is returned once, with the error-path identifying the list This error is returned once, with the error-path identifying the list
node, even if there are more than one child missing. node, even if there are more than one child missing.
12.4. Error Message for Data that Violates a YANG must statement: 13.4. Error Message for Data that Violates a YANG must statement:
If a NETCONF operation would result in configuration data where the If a NETCONF operation would result in configuration data where the
restrictions imposed by a "must" statement is violated the following restrictions imposed by a "must" statement is violated the following
error is returned, unless a specific "error-app-tag" substatement is error is returned, unless a specific "error-app-tag" substatement is
present for the "must" statement. present for the "must" statement.
Tag: operation-failed Tag: operation-failed
Error-app-tag: must-violation Error-app-tag: must-violation
12.5. Error Message for the "insert" Operation 13.5. Error Message for the "insert" Operation
If the "insert" and "key" or "value" attributes are used in an <edit- If the "insert" and "key" or "value" attributes are used in an <edit-
config> for a list or leaf-list node, and the "key" or "value" refers config> for a list or leaf-list node, and the "key" or "value" refers
to a non-existing instance, the following error is returned: to a non-existing instance, the following error is returned:
Tag: bad-attribute Tag: bad-attribute
Error-app-tag: missing-instance Error-app-tag: missing-instance
13. IANA Considerations 14. IANA Considerations
This document registers two URIs for the YANG XML namespace in the This document registers two URIs for the YANG XML namespace in the
IETF XML registry [RFC3688]. IETF XML registry [RFC3688].
URI: urn:ietf:params:xml:ns:yang:yin:1 URI: urn:ietf:params:xml:ns:yang:yin:1
URI: urn:ietf:params:xml:ns:yang:1 URI: urn:ietf:params:xml:ns:yang:1
14. Security Considerations 15. Security Considerations
This document defines a language with which to write and read This document defines a language with which to write and read
descriptions of management information. The language itself has no descriptions of management information. The language itself has no
security impact on the Internet. security impact on the Internet.
Data modeled in YANG might contain sensitive information. RPCs or Data modeled in YANG might contain sensitive information. RPCs or
notifications defined in YANG might transfer sensitive information. notifications defined in YANG might transfer sensitive information.
</