draft-ietf-netmod-rfc6020bis-03.txt   draft-ietf-netmod-rfc6020bis-04.txt 
Network Working Group M. Bjorklund, Ed. Network Working Group M. Bjorklund, Ed.
Internet-Draft Tail-f Systems Internet-Draft Tail-f Systems
Obsoletes: 6020 (if approved) January 5, 2015 Obsoletes: 6020 (if approved) March 9, 2015
Intended status: Standards Track Intended status: Standards Track
Expires: July 9, 2015 Expires: September 10, 2015
YANG - A Data Modeling Language for the Network Configuration Protocol YANG - A Data Modeling Language for the Network Configuration Protocol
(NETCONF) (NETCONF)
draft-ietf-netmod-rfc6020bis-03 draft-ietf-netmod-rfc6020bis-04
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 Network Configuration Protocol state data manipulated by the Network Configuration Protocol
(NETCONF), NETCONF remote procedure calls, and NETCONF notifications. (NETCONF), NETCONF remote procedure calls, and NETCONF notifications.
This document obsoletes RFC 6020. This document obsoletes RFC 6020.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 9, 2015. This Internet-Draft will expire on September 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 23
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1. Summary of Changes from RFC 6020 . . . . . . . . . . . . 8 1.1. Summary of Changes from RFC 6020 . . . . . . . . . . . . 8
2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Mandatory Nodes . . . . . . . . . . . . . . . . . . . . . 12 3.1. Mandatory Nodes . . . . . . . . . . . . . . . . . . . . . 12
4. YANG Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 4. YANG Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Functional Overview . . . . . . . . . . . . . . . . . . . 12 4.1. Functional Overview . . . . . . . . . . . . . . . . . . . 12
4.2. Language Overview . . . . . . . . . . . . . . . . . . . . 14 4.2. Language Overview . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Modules and Submodules . . . . . . . . . . . . . . . 14 4.2.1. Modules and Submodules . . . . . . . . . . . . . . . 14
4.2.2. Data Modeling Basics . . . . . . . . . . . . . . . . 15 4.2.2. Data Modeling Basics . . . . . . . . . . . . . . . . 15
4.2.3. State Data . . . . . . . . . . . . . . . . . . . . . 19 4.2.3. State Data . . . . . . . . . . . . . . . . . . . . . 19
4.2.4. Built-In Types . . . . . . . . . . . . . . . . . . . 19 4.2.4. Built-In Types . . . . . . . . . . . . . . . . . . . 19
4.2.5. Derived Types (typedef) . . . . . . . . . . . . . . . 20 4.2.5. Derived Types (typedef) . . . . . . . . . . . . . . . 20
4.2.6. Reusable Node Groups (grouping) . . . . . . . . . . . 21 4.2.6. Reusable Node Groups (grouping) . . . . . . . . . . . 21
4.2.7. Choices . . . . . . . . . . . . . . . . . . . . . . . 22 4.2.7. Choices . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.8. Extending Data Models (augment) . . . . . . . . . . . 23 4.2.8. Extending Data Models (augment) . . . . . . . . . . . 23
4.2.9. RPC Definitions . . . . . . . . . . . . . . . . . . . 24 4.2.9. Operation Definitions . . . . . . . . . . . . . . . . 24
4.2.10. Notification Definitions . . . . . . . . . . . . . . 25 4.2.10. Notification Definitions . . . . . . . . . . . . . . 25
5. Language Concepts . . . . . . . . . . . . . . . . . . . . . . 26 5. Language Concepts . . . . . . . . . . . . . . . . . . . . . . 26
5.1. Modules and Submodules . . . . . . . . . . . . . . . . . 26 5.1. Modules and Submodules . . . . . . . . . . . . . . . . . 26
5.1.1. Import and Include by Revision . . . . . . . . . . . 27 5.1.1. Import and Include by Revision . . . . . . . . . . . 27
5.1.2. Module Hierarchies . . . . . . . . . . . . . . . . . 28 5.1.2. Module Hierarchies . . . . . . . . . . . . . . . . . 28
5.2. File Layout . . . . . . . . . . . . . . . . . . . . . . . 29 5.2. File Layout . . . . . . . . . . . . . . . . . . . . . . . 29
5.3. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 29 5.3. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 30
5.3.1. YANG XML Namespace . . . . . . . . . . . . . . . . . 30 5.3.1. YANG XML Namespace . . . . . . . . . . . . . . . . . 30
5.4. Resolving Grouping, Type, and Identity Names . . . . . . 30 5.4. Resolving Grouping, Type, and Identity Names . . . . . . 30
5.5. Nested Typedefs and Groupings . . . . . . . . . . . . . . 30 5.5. Nested Typedefs and Groupings . . . . . . . . . . . . . . 30
5.6. Conformance . . . . . . . . . . . . . . . . . . . . . . . 31 5.6. Conformance . . . . . . . . . . . . . . . . . . . . . . . 31
5.6.1. Basic Behavior . . . . . . . . . . . . . . . . . . . 31 5.6.1. Basic Behavior . . . . . . . . . . . . . . . . . . . 32
5.6.2. Optional Features . . . . . . . . . . . . . . . . . . 32 5.6.2. Optional Features . . . . . . . . . . . . . . . . . . 32
5.6.3. Deviations . . . . . . . . . . . . . . . . . . . . . 32 5.6.3. Deviations . . . . . . . . . . . . . . . . . . . . . 32
5.6.4. Announcing Conformance Information in the <hello> 5.6.4. Announcing Conformance Information in the <hello>
Message . . . . . . . . . . . . . . . . . . . . . . . 33 Message . . . . . . . . . . . . . . . . . . . . . . . 33
5.7. Data Store Modification . . . . . . . . . . . . . . . . . 35 5.7. Data Store Modification . . . . . . . . . . . . . . . . . 33
6. YANG Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 35 6. YANG Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.1. Lexical Tokenization . . . . . . . . . . . . . . . . . . 35 6.1. Lexical Tokenization . . . . . . . . . . . . . . . . . . 34
6.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 36 6.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 34
6.1.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 36 6.1.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 34
6.1.3. Quoting . . . . . . . . . . . . . . . . . . . . . . . 36 6.1.3. Quoting . . . . . . . . . . . . . . . . . . . . . . . 34
6.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 37 6.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 36
6.2.1. Identifiers and Their Namespaces . . . . . . . . . . 38 6.2.1. Identifiers and Their Namespaces . . . . . . . . . . 36
6.3. Statements . . . . . . . . . . . . . . . . . . . . . . . 39 6.3. Statements . . . . . . . . . . . . . . . . . . . . . . . 37
6.3.1. Language Extensions . . . . . . . . . . . . . . . . . 39 6.3.1. Language Extensions . . . . . . . . . . . . . . . . . 37
6.4. XPath Evaluations . . . . . . . . . . . . . . . . . . . . 39 6.4. XPath Evaluations . . . . . . . . . . . . . . . . . . . . 38
6.4.1. XPath Context . . . . . . . . . . . . . . . . . . . . 40 6.4.1. XPath Context . . . . . . . . . . . . . . . . . . . . 38
6.5. Schema Node Identifier . . . . . . . . . . . . . . . . . 41 6.5. Schema Node Identifier . . . . . . . . . . . . . . . . . 40
7. YANG Statements . . . . . . . . . . . . . . . . . . . . . . . 42 7. YANG Statements . . . . . . . . . . . . . . . . . . . . . . . 40
7.1. The module Statement . . . . . . . . . . . . . . . . . . 42 7.1. The module Statement . . . . . . . . . . . . . . . . . . 41
7.1.1. The module's Substatements . . . . . . . . . . . . . 43 7.1.1. The module's Substatements . . . . . . . . . . . . . 42
7.1.2. The yang-version Statement . . . . . . . . . . . . . 44 7.1.2. The yang-version Statement . . . . . . . . . . . . . 43
7.1.3. The namespace Statement . . . . . . . . . . . . . . . 45 7.1.3. The namespace Statement . . . . . . . . . . . . . . . 44
7.1.4. The prefix Statement . . . . . . . . . . . . . . . . 45 7.1.4. The prefix Statement . . . . . . . . . . . . . . . . 44
7.1.5. The import Statement . . . . . . . . . . . . . . . . 45 7.1.5. The import Statement . . . . . . . . . . . . . . . . 44
7.1.6. The include Statement . . . . . . . . . . . . . . . . 46 7.1.6. The include Statement . . . . . . . . . . . . . . . . 45
7.1.7. The organization Statement . . . . . . . . . . . . . 47 7.1.7. The organization Statement . . . . . . . . . . . . . 46
7.1.8. The contact Statement . . . . . . . . . . . . . . . . 47 7.1.8. The contact Statement . . . . . . . . . . . . . . . . 46
7.1.9. The revision Statement . . . . . . . . . . . . . . . 47 7.1.9. The revision Statement . . . . . . . . . . . . . . . 46
7.1.10. Usage Example . . . . . . . . . . . . . . . . . . . . 48 7.1.10. Usage Example . . . . . . . . . . . . . . . . . . . . 47
7.2. The submodule Statement . . . . . . . . . . . . . . . . . 49 7.2. The submodule Statement . . . . . . . . . . . . . . . . . 48
7.2.1. The submodule's Substatements . . . . . . . . . . . . 50 7.2.1. The submodule's Substatements . . . . . . . . . . . . 49
7.2.2. The belongs-to Statement . . . . . . . . . . . . . . 51 7.2.2. The belongs-to Statement . . . . . . . . . . . . . . 50
7.2.3. Usage Example . . . . . . . . . . . . . . . . . . . . 52 7.2.3. Usage Example . . . . . . . . . . . . . . . . . . . . 51
7.3. The typedef Statement . . . . . . . . . . . . . . . . . . 52 7.3. The typedef Statement . . . . . . . . . . . . . . . . . . 51
7.3.1. The typedef's Substatements . . . . . . . . . . . . . 53 7.3.1. The typedef's Substatements . . . . . . . . . . . . . 52
7.3.2. The typedef's type Statement . . . . . . . . . . . . 53 7.3.2. The typedef's type Statement . . . . . . . . . . . . 52
7.3.3. The units Statement . . . . . . . . . . . . . . . . . 53 7.3.3. The units Statement . . . . . . . . . . . . . . . . . 52
7.3.4. The typedef's default Statement . . . . . . . . . . . 53 7.3.4. The typedef's default Statement . . . . . . . . . . . 52
7.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 54 7.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 53
7.4. The type Statement . . . . . . . . . . . . . . . . . . . 54 7.4. The type Statement . . . . . . . . . . . . . . . . . . . 53
7.4.1. The type's Substatements . . . . . . . . . . . . . . 54 7.4.1. The type's Substatements . . . . . . . . . . . . . . 53
7.5. The container Statement . . . . . . . . . . . . . . . . . 54 7.5. The container Statement . . . . . . . . . . . . . . . . . 53
7.5.1. Containers with Presence . . . . . . . . . . . . . . 55 7.5.1. Containers with Presence . . . . . . . . . . . . . . 54
7.5.2. The container's Substatements . . . . . . . . . . . . 55 7.5.2. The container's Substatements . . . . . . . . . . . . 54
7.5.3. The must Statement . . . . . . . . . . . . . . . . . 56 7.5.3. The must Statement . . . . . . . . . . . . . . . . . 55
7.5.4. The must's Substatements . . . . . . . . . . . . . . 57 7.5.4. The must's Substatements . . . . . . . . . . . . . . 56
7.5.5. The presence Statement . . . . . . . . . . . . . . . 58 7.5.5. The presence Statement . . . . . . . . . . . . . . . 57
7.5.6. The container's Child Node Statements . . . . . . . . 58 7.5.6. The container's Child Node Statements . . . . . . . . 57
7.5.7. XML Mapping Rules . . . . . . . . . . . . . . . . . . 58 7.5.7. XML Mapping Rules . . . . . . . . . . . . . . . . . . 57
7.5.8. NETCONF <edit-config> Operations . . . . . . . . . . 59 7.5.8. NETCONF <edit-config> Operations . . . . . . . . . . 58
7.5.9. Usage Example . . . . . . . . . . . . . . . . . . . . 59 7.5.9. Usage Example . . . . . . . . . . . . . . . . . . . . 58
7.6. The leaf Statement . . . . . . . . . . . . . . . . . . . 60 7.6. The leaf Statement . . . . . . . . . . . . . . . . . . . 59
7.6.1. The leaf's default value . . . . . . . . . . . . . . 61 7.6.1. The leaf's default value . . . . . . . . . . . . . . 60
7.6.2. The leaf's Substatements . . . . . . . . . . . . . . 61 7.6.2. The leaf's Substatements . . . . . . . . . . . . . . 60
7.6.3. The leaf's type Statement . . . . . . . . . . . . . . 62 7.6.3. The leaf's type Statement . . . . . . . . . . . . . . 61
7.6.4. The leaf's default Statement . . . . . . . . . . . . 62 7.6.4. The leaf's default Statement . . . . . . . . . . . . 61
7.6.5. The leaf's mandatory Statement . . . . . . . . . . . 62 7.6.5. The leaf's mandatory Statement . . . . . . . . . . . 61
7.6.6. XML Mapping Rules . . . . . . . . . . . . . . . . . . 62 7.6.6. XML Mapping Rules . . . . . . . . . . . . . . . . . . 61
7.6.7. NETCONF <edit-config> Operations . . . . . . . . . . 63 7.6.7. NETCONF <edit-config> Operations . . . . . . . . . . 62
7.6.8. Usage Example . . . . . . . . . . . . . . . . . . . . 63 7.6.8. Usage Example . . . . . . . . . . . . . . . . . . . . 62
7.7. The leaf-list Statement . . . . . . . . . . . . . . . . . 64 7.7. The leaf-list Statement . . . . . . . . . . . . . . . . . 63
7.7.1. Ordering . . . . . . . . . . . . . . . . . . . . . . 64 7.7.1. Ordering . . . . . . . . . . . . . . . . . . . . . . 63
7.7.2. The leaf-list's default values . . . . . . . . . . . 65 7.7.2. The leaf-list's default values . . . . . . . . . . . 64
7.7.3. The leaf-list's Substatements . . . . . . . . . . . . 66 7.7.3. The leaf-list's Substatements . . . . . . . . . . . . 65
7.7.4. The leaf-list's default Statement . . . . . . . . . . 66 7.7.4. The leaf-list's default Statement . . . . . . . . . . 65
7.7.5. The min-elements Statement . . . . . . . . . . . . . 66 7.7.5. The min-elements Statement . . . . . . . . . . . . . 65
7.7.6. The max-elements Statement . . . . . . . . . . . . . 67 7.7.6. The max-elements Statement . . . . . . . . . . . . . 66
7.7.7. The ordered-by Statement . . . . . . . . . . . . . . 67 7.7.7. The ordered-by Statement . . . . . . . . . . . . . . 66
7.7.8. XML Mapping Rules . . . . . . . . . . . . . . . . . . 68 7.7.8. XML Mapping Rules . . . . . . . . . . . . . . . . . . 67
7.7.9. NETCONF <edit-config> Operations . . . . . . . . . . 68 7.7.9. NETCONF <edit-config> Operations . . . . . . . . . . 67
7.7.10. Usage Example . . . . . . . . . . . . . . . . . . . . 69 7.7.10. Usage Example . . . . . . . . . . . . . . . . . . . . 68
7.8. The list Statement . . . . . . . . . . . . . . . . . . . 71 7.8. The list Statement . . . . . . . . . . . . . . . . . . . 70
7.8.1. The list's Substatements . . . . . . . . . . . . . . 71 7.8.1. The list's Substatements . . . . . . . . . . . . . . 70
7.8.2. The list's key Statement . . . . . . . . . . . . . . 72 7.8.2. The list's key Statement . . . . . . . . . . . . . . 71
7.8.3. The list's unique Statement . . . . . . . . . . . . . 73 7.8.3. The list's unique Statement . . . . . . . . . . . . . 72
7.8.4. The list's Child Node Statements . . . . . . . . . . 74 7.8.4. The list's Child Node Statements . . . . . . . . . . 73
7.8.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 74 7.8.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 73
7.8.6. NETCONF <edit-config> Operations . . . . . . . . . . 75 7.8.6. NETCONF <edit-config> Operations . . . . . . . . . . 74
7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 76 7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 75
7.9. The choice Statement . . . . . . . . . . . . . . . . . . 79 7.9. The choice Statement . . . . . . . . . . . . . . . . . . 78
7.9.1. The choice's Substatements . . . . . . . . . . . . . 79 7.9.1. The choice's Substatements . . . . . . . . . . . . . 78
7.9.2. The choice's case Statement . . . . . . . . . . . . . 80 7.9.2. The choice's case Statement . . . . . . . . . . . . . 79
7.9.3. The choice's default Statement . . . . . . . . . . . 81 7.9.3. The choice's default Statement . . . . . . . . . . . 80
7.9.4. The choice's mandatory Statement . . . . . . . . . . 83 7.9.4. The choice's mandatory Statement . . . . . . . . . . 82
7.9.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 83 7.9.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 82
7.9.6. NETCONF <edit-config> Operations . . . . . . . . . . 83 7.9.6. NETCONF <edit-config> Operations . . . . . . . . . . 82
7.9.7. Usage Example . . . . . . . . . . . . . . . . . . . . 83 7.9.7. Usage Example . . . . . . . . . . . . . . . . . . . . 82
7.10. The anyxml Statement . . . . . . . . . . . . . . . . . . 84 7.10. The anyxml Statement . . . . . . . . . . . . . . . . . . 83
7.10.1. The anyxml's Substatements . . . . . . . . . . . . . 85 7.10.1. The anyxml's Substatements . . . . . . . . . . . . . 84
7.10.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 85 7.10.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 84
7.10.3. NETCONF <edit-config> Operations . . . . . . . . . . 85 7.10.3. NETCONF <edit-config> Operations . . . . . . . . . . 84
7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . 86 7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . 85
7.11. The grouping Statement . . . . . . . . . . . . . . . . . 86 7.11. The grouping Statement . . . . . . . . . . . . . . . . . 85
7.11.1. The grouping's Substatements . . . . . . . . . . . . 87 7.11.1. The grouping's Substatements . . . . . . . . . . . . 86
7.11.2. Usage Example . . . . . . . . . . . . . . . . . . . 87 7.11.2. Usage Example . . . . . . . . . . . . . . . . . . . 86
7.12. The uses Statement . . . . . . . . . . . . . . . . . . . 88 7.12. The uses Statement . . . . . . . . . . . . . . . . . . . 87
7.12.1. The uses's Substatements . . . . . . . . . . . . . . 88 7.12.1. The uses's Substatements . . . . . . . . . . . . . . 87
7.12.2. The refine Statement . . . . . . . . . . . . . . . . 88 7.12.2. The refine Statement . . . . . . . . . . . . . . . . 87
7.12.3. XML Mapping Rules . . . . . . . . . . . . . . . . . 89 7.12.3. XML Mapping Rules . . . . . . . . . . . . . . . . . 88
7.12.4. Usage Example . . . . . . . . . . . . . . . . . . . 89 7.12.4. Usage Example . . . . . . . . . . . . . . . . . . . 88
7.13. The rpc Statement . . . . . . . . . . . . . . . . . . . . 91 7.13. The rpc Statement . . . . . . . . . . . . . . . . . . . . 90
7.13.1. The rpc's Substatements . . . . . . . . . . . . . . 91 7.13.1. The rpc's Substatements . . . . . . . . . . . . . . 90
7.13.2. The input Statement . . . . . . . . . . . . . . . . 91 7.13.2. The input Statement . . . . . . . . . . . . . . . . 90
7.13.3. The output Statement . . . . . . . . . . . . . . . . 92 7.13.3. The output Statement . . . . . . . . . . . . . . . . 91
7.13.4. XML Mapping Rules . . . . . . . . . . . . . . . . . 93 7.13.4. XML Mapping Rules . . . . . . . . . . . . . . . . . 92
7.13.5. Usage Example . . . . . . . . . . . . . . . . . . . 94 7.13.5. Usage Example . . . . . . . . . . . . . . . . . . . 93
7.14. The notification Statement . . . . . . . . . . . . . . . 94 7.14. The action Statement . . . . . . . . . . . . . . . . . . 93
7.14.1. The notification's Substatements . . . . . . . . . . 95 7.14.1. The action's Substatements . . . . . . . . . . . . . 94
7.14.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 95 7.14.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 94
7.14.3. Usage Example . . . . . . . . . . . . . . . . . . . 95 7.14.3. Usage Example . . . . . . . . . . . . . . . . . . . 95
7.15. The augment Statement . . . . . . . . . . . . . . . . . . 96 7.15. The notification Statement . . . . . . . . . . . . . . . 96
7.15.1. The augment's Substatements . . . . . . . . . . . . 97 7.15.1. The notification's Substatements . . . . . . . . . . 97
7.15.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 97 7.15.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 97
7.15.3. Usage Example . . . . . . . . . . . . . . . . . . . 98 7.15.3. Usage Example . . . . . . . . . . . . . . . . . . . 97
7.16. The identity Statement . . . . . . . . . . . . . . . . . 100 7.16. The augment Statement . . . . . . . . . . . . . . . . . . 98
7.16.1. The identity's Substatements . . . . . . . . . . . . 100 7.16.1. The augment's Substatements . . . . . . . . . . . . 99
7.16.2. The base Statement . . . . . . . . . . . . . . . . . 100 7.16.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 99
7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . 101 7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . 99
7.17. The extension Statement . . . . . . . . . . . . . . . . . 101 7.17. The identity Statement . . . . . . . . . . . . . . . . . 101
7.17.1. The extension's Substatements . . . . . . . . . . . 102 7.17.1. The identity's Substatements . . . . . . . . . . . . 101
7.17.2. The argument Statement . . . . . . . . . . . . . . . 102 7.17.2. The base Statement . . . . . . . . . . . . . . . . . 102
7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . 103 7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . 102
7.18. Conformance-Related Statements . . . . . . . . . . . . . 103 7.18. The extension Statement . . . . . . . . . . . . . . . . . 103
7.18.1. The feature Statement . . . . . . . . . . . . . . . 104 7.18.1. The extension's Substatements . . . . . . . . . . . 104
7.18.2. The if-feature Statement . . . . . . . . . . . . . . 105 7.18.2. The argument Statement . . . . . . . . . . . . . . . 104
7.18.3. The deviation Statement . . . . . . . . . . . . . . 106 7.18.3. Usage Example . . . . . . . . . . . . . . . . . . . 105
7.19. Common Statements . . . . . . . . . . . . . . . . . . . . 109 7.19. Conformance-Related Statements . . . . . . . . . . . . . 105
7.19.1. The config Statement . . . . . . . . . . . . . . . . 109 7.19.1. The feature Statement . . . . . . . . . . . . . . . 105
7.19.2. The status Statement . . . . . . . . . . . . . . . . 109 7.19.2. The if-feature Statement . . . . . . . . . . . . . . 107
7.19.3. The description Statement . . . . . . . . . . . . . 110 7.19.3. The deviation Statement . . . . . . . . . . . . . . 108
7.19.4. The reference Statement . . . . . . . . . . . . . . 110 7.20. Common Statements . . . . . . . . . . . . . . . . . . . . 110
7.19.5. The when Statement . . . . . . . . . . . . . . . . . 111 7.20.1. The config Statement . . . . . . . . . . . . . . . . 110
8. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 111 7.20.2. The status Statement . . . . . . . . . . . . . . . . 111
8.1. Constraints on Data . . . . . . . . . . . . . . . . . . . 112 7.20.3. The description Statement . . . . . . . . . . . . . 112
8.2. Hierarchy of Constraints . . . . . . . . . . . . . . . . 112 7.20.4. The reference Statement . . . . . . . . . . . . . . 112
8.3. Constraint Enforcement Model . . . . . . . . . . . . . . 112 7.20.5. The when Statement . . . . . . . . . . . . . . . . . 112
8.3.1. Payload Parsing . . . . . . . . . . . . . . . . . . . 113 8. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 113
8.3.2. NETCONF <edit-config> Processing . . . . . . . . . . 113 8.1. Constraints on Data . . . . . . . . . . . . . . . . . . . 113
8.3.3. Validation . . . . . . . . . . . . . . . . . . . . . 114 8.2. Hierarchy of Constraints . . . . . . . . . . . . . . . . 114
9. Built-In Types . . . . . . . . . . . . . . . . . . . . . . . 114 8.3. Constraint Enforcement Model . . . . . . . . . . . . . . 114
9.1. Canonical Representation . . . . . . . . . . . . . . . . 115 8.3.1. Payload Parsing . . . . . . . . . . . . . . . . . . . 114
9.2. The Integer Built-In Types . . . . . . . . . . . . . . . 115 8.3.2. NETCONF <edit-config> Processing . . . . . . . . . . 115
9.2.1. Lexical Representation . . . . . . . . . . . . . . . 116 8.3.3. Validation . . . . . . . . . . . . . . . . . . . . . 116
9.2.2. Canonical Form . . . . . . . . . . . . . . . . . . . 116 9. Built-In Types . . . . . . . . . . . . . . . . . . . . . . . 116
9.2.3. Restrictions . . . . . . . . . . . . . . . . . . . . 116 9.1. Canonical Representation . . . . . . . . . . . . . . . . 116
9.2.4. The range Statement . . . . . . . . . . . . . . . . . 117 9.2. The Integer Built-In Types . . . . . . . . . . . . . . . 117
9.2.5. Usage Example . . . . . . . . . . . . . . . . . . . . 117 9.2.1. Lexical Representation . . . . . . . . . . . . . . . 117
9.3. The decimal64 Built-In Type . . . . . . . . . . . . . . . 118 9.2.2. Canonical Form . . . . . . . . . . . . . . . . . . . 118
9.3.1. Lexical Representation . . . . . . . . . . . . . . . 118 9.2.3. Restrictions . . . . . . . . . . . . . . . . . . . . 118
9.3.2. Canonical Form . . . . . . . . . . . . . . . . . . . 118 9.2.4. The range Statement . . . . . . . . . . . . . . . . . 118
9.3.3. Restrictions . . . . . . . . . . . . . . . . . . . . 119 9.2.5. Usage Example . . . . . . . . . . . . . . . . . . . . 119
9.3.4. The fraction-digits Statement . . . . . . . . . . . . 119 9.3. The decimal64 Built-In Type . . . . . . . . . . . . . . . 119
9.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 119 9.3.1. Lexical Representation . . . . . . . . . . . . . . . 120
9.4. The string Built-In Type . . . . . . . . . . . . . . . . 120 9.3.2. Canonical Form . . . . . . . . . . . . . . . . . . . 120
9.4.1. Lexical Representation . . . . . . . . . . . . . . . 120 9.3.3. Restrictions . . . . . . . . . . . . . . . . . . . . 120
9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 120 9.3.4. The fraction-digits Statement . . . . . . . . . . . . 120
9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 120 9.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 121
9.4.4. The length Statement . . . . . . . . . . . . . . . . 120 9.4. The string Built-In Type . . . . . . . . . . . . . . . . 121
9.4.5. The pattern Statement . . . . . . . . . . . . . . . . 121 9.4.1. Lexical Representation . . . . . . . . . . . . . . . 121
9.4.6. The modifier Statement . . . . . . . . . . . . . . . 121 9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 122
9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 121 9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 122
9.5. The boolean Built-In Type . . . . . . . . . . . . . . . . 123 9.4.4. The length Statement . . . . . . . . . . . . . . . . 122
9.5.1. Lexical Representation . . . . . . . . . . . . . . . 123 9.4.5. The pattern Statement . . . . . . . . . . . . . . . . 123
9.5.2. Canonical Form . . . . . . . . . . . . . . . . . . . 123 9.4.6. The modifier Statement . . . . . . . . . . . . . . . 123
9.5.3. Restrictions . . . . . . . . . . . . . . . . . . . . 123 9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 123
9.6. The enumeration Built-In Type . . . . . . . . . . . . . . 123 9.5. The boolean Built-In Type . . . . . . . . . . . . . . . . 124
9.6.1. Lexical Representation . . . . . . . . . . . . . . . 123 9.5.1. Lexical Representation . . . . . . . . . . . . . . . 125
9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 123 9.5.2. Canonical Form . . . . . . . . . . . . . . . . . . . 125
9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 123 9.5.3. Restrictions . . . . . . . . . . . . . . . . . . . . 125
9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 124 9.6. The enumeration Built-In Type . . . . . . . . . . . . . . 125
9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 125 9.6.1. Lexical Representation . . . . . . . . . . . . . . . 125
9.7. The bits Built-In Type . . . . . . . . . . . . . . . . . 126 9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 125
9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 126 9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 125
9.7.2. Lexical Representation . . . . . . . . . . . . . . . 126 9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 125
9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 126 9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 126
9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 126 9.7. The bits Built-In Type . . . . . . . . . . . . . . . . . 128
9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 127 9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 128
9.8. The binary Built-In Type . . . . . . . . . . . . . . . . 128 9.7.2. Lexical Representation . . . . . . . . . . . . . . . 128
9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 128 9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 128
9.8.2. Lexical Representation . . . . . . . . . . . . . . . 128 9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 128
9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 128 9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 129
9.9. The leafref Built-In Type . . . . . . . . . . . . . . . . 128 9.8. The binary Built-In Type . . . . . . . . . . . . . . . . 130
9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 129 9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 130
9.9.2. The path Statement . . . . . . . . . . . . . . . . . 129 9.8.2. Lexical Representation . . . . . . . . . . . . . . . 130
9.9.3. The require-instance Statement . . . . . . . . . . . 130 9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 130
9.9.4. Lexical Representation . . . . . . . . . . . . . . . 130 9.9. The leafref Built-In Type . . . . . . . . . . . . . . . . 130
9.9.5. Canonical Form . . . . . . . . . . . . . . . . . . . 130 9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 131
9.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 130 9.9.2. The path Statement . . . . . . . . . . . . . . . . . 131
9.10. The identityref Built-In Type . . . . . . . . . . . . . . 134 9.9.3. The require-instance Statement . . . . . . . . . . . 131
9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 134 9.9.4. Lexical Representation . . . . . . . . . . . . . . . 132
9.10.2. The identityref's base Statement . . . . . . . . . . 134 9.9.5. Canonical Form . . . . . . . . . . . . . . . . . . . 132
9.10.3. Lexical Representation . . . . . . . . . . . . . . . 135 9.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 132
9.10.4. Canonical Form . . . . . . . . . . . . . . . . . . . 135 9.10. The identityref Built-In Type . . . . . . . . . . . . . . 136
9.10.5. Usage Example . . . . . . . . . . . . . . . . . . . 135 9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 136
9.10.2. The identityref's base Statement . . . . . . . . . . 136
9.11. The empty Built-In Type . . . . . . . . . . . . . . . . . 137 9.10.3. Lexical Representation . . . . . . . . . . . . . . . 136
9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 137 9.10.4. Canonical Form . . . . . . . . . . . . . . . . . . . 137
9.11.2. Lexical Representation . . . . . . . . . . . . . . . 137 9.10.5. Usage Example . . . . . . . . . . . . . . . . . . . 137
9.11.3. Canonical Form . . . . . . . . . . . . . . . . . . . 137 9.11. The empty Built-In Type . . . . . . . . . . . . . . . . . 138
9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 137 9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 138
9.12. The union Built-In Type . . . . . . . . . . . . . . . . . 137 9.11.2. Lexical Representation . . . . . . . . . . . . . . . 138
9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 138 9.11.3. Canonical Form . . . . . . . . . . . . . . . . . . . 138
9.12.2. Lexical Representation . . . . . . . . . . . . . . . 138 9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 138
9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 138 9.12. The union Built-In Type . . . . . . . . . . . . . . . . . 139
9.12.4. Usage Example . . . . . . . . . . . . . . . . . . . 138 9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 139
9.13. The instance-identifier Built-In Type . . . . . . . . . . 139 9.12.2. Lexical Representation . . . . . . . . . . . . . . . 139
9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 140 9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 139
9.13.2. Lexical Representation . . . . . . . . . . . . . . . 140 9.12.4. Usage Example . . . . . . . . . . . . . . . . . . . 139
9.13.3. Canonical Form . . . . . . . . . . . . . . . . . . . 140 9.13. The instance-identifier Built-In Type . . . . . . . . . . 140
9.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 140 9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 141
10. XPath Functions . . . . . . . . . . . . . . . . . . . . . . . 141 9.13.2. Lexical Representation . . . . . . . . . . . . . . . 141
10.1. Functions for Node Sets . . . . . . . . . . . . . . . . 141 9.13.3. Canonical Form . . . . . . . . . . . . . . . . . . . 141
10.1.1. current() . . . . . . . . . . . . . . . . . . . . . 141 9.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 141
10.2. Functions for Strings . . . . . . . . . . . . . . . . . 141 10. XPath Functions . . . . . . . . . . . . . . . . . . . . . . . 142
10.2.1. re-match() . . . . . . . . . . . . . . . . . . . . . 141 10.1. Functions for Node Sets . . . . . . . . . . . . . . . . 142
10.1.1. current() . . . . . . . . . . . . . . . . . . . . . 142
10.2. Functions for Strings . . . . . . . . . . . . . . . . . 142
10.2.1. re-match() . . . . . . . . . . . . . . . . . . . . . 142
10.3. Functions for the YANG Types "leafref" and "instance- 10.3. Functions for the YANG Types "leafref" and "instance-
identifier" . . . . . . . . . . . . . . . . . . . . . . 142 identifier" . . . . . . . . . . . . . . . . . . . . . . 143
10.3.1. deref() . . . . . . . . . . . . . . . . . . . . . . 142 10.3.1. deref() . . . . . . . . . . . . . . . . . . . . . . 143
10.4. Functions for the YANG Type "identityref" . . . . . . . 143 10.4. Functions for the YANG Type "identityref" . . . . . . . 144
10.4.1. derived-from() . . . . . . . . . . . . . . . . . . . 143 10.4.1. derived-from() . . . . . . . . . . . . . . . . . . . 144
10.4.2. derived-from-or-self() . . . . . . . . . . . . . . . 143 10.4.2. derived-from-or-self() . . . . . . . . . . . . . . . 144
10.5. Functions for the YANG Type "enumeration" . . . . . . . 144 10.5. Functions for the YANG Type "enumeration" . . . . . . . 145
10.5.1. enum-value() . . . . . . . . . . . . . . . . . . . . 144 10.5.1. enum-value() . . . . . . . . . . . . . . . . . . . . 145
10.6. Functions for the YANG Type "bits" . . . . . . . . . . . 145 10.6. Functions for the YANG Type "bits" . . . . . . . . . . . 146
10.6.1. bit-is-set() . . . . . . . . . . . . . . . . . . . . 145 10.6.1. bit-is-set() . . . . . . . . . . . . . . . . . . . . 146
11. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 146 11. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 147
12. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 12. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
12.1. Formal YIN Definition . . . . . . . . . . . . . . . . . 149 12.1. Formal YIN Definition . . . . . . . . . . . . . . . . . 150
12.1.1. Usage Example . . . . . . . . . . . . . . . . . . . 151 12.1.1. Usage Example . . . . . . . . . . . . . . . . . . . 152
13. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 152 13. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 153
14. Error Responses for YANG Related Errors . . . . . . . . . . . 176 14. Error Responses for YANG Related Errors . . . . . . . . . . . 177
14.1. Error Message for Data That Violates a unique Statement 176 14.1. Error Message for Data That Violates a unique Statement 177
14.2. Error Message for Data That Violates a max-elements 14.2. Error Message for Data That Violates a max-elements
Statement . . . . . . . . . . . . . . . . . . . . . . . 176 Statement . . . . . . . . . . . . . . . . . . . . . . . 177
14.3. Error Message for Data That Violates a min-elements 14.3. Error Message for Data That Violates a min-elements
Statement . . . . . . . . . . . . . . . . . . . . . . . 176
14.4. Error Message for Data That Violates a must Statement . 177
14.5. Error Message for Data That Violates a require-instance
Statement . . . . . . . . . . . . . . . . . . . . . . . 177 Statement . . . . . . . . . . . . . . . . . . . . . . . 177
14.4. Error Message for Data That Violates a must Statement . 178
14.5. Error Message for Data That Violates a require-instance
Statement . . . . . . . . . . . . . . . . . . . . . . . 178
14.6. Error Message for Data That Does Not Match a leafref 14.6. Error Message for Data That Does Not Match a leafref
Type . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Type . . . . . . . . . . . . . . . . . . . . . . . . . . 178
14.7. Error Message for Data That Violates a mandatory choice 14.7. Error Message for Data That Violates a mandatory choice
Statement . . . . . . . . . . . . . . . . . . . . . . . 177 Statement . . . . . . . . . . . . . . . . . . . . . . . 178
14.8. Error Message for the "insert" Operation . . . . . . . . 179
14.8. Error Message for the "insert" Operation . . . . . . . . 178 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 179
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 178 15.1. Media type application/yang . . . . . . . . . . . . . . 180
15.1. Media type application/yang . . . . . . . . . . . . . . 179 15.2. Media type application/yin+xml . . . . . . . . . . . . . 181
15.2. Media type application/yin+xml . . . . . . . . . . . . . 180 16. Security Considerations . . . . . . . . . . . . . . . . . . . 183
16. Security Considerations . . . . . . . . . . . . . . . . . . . 182 17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 183
17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 182 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 184
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 183 19. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 184
19. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 183 19.1. Version -04 . . . . . . . . . . . . . . . . . . . . . . 184
19.1. Version -03 . . . . . . . . . . . . . . . . . . . . . . 183 19.2. Version -03 . . . . . . . . . . . . . . . . . . . . . . 184
19.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . 183 19.3. Version -02 . . . . . . . . . . . . . . . . . . . . . . 184
19.3. Version -01 . . . . . . . . . . . . . . . . . . . . . . 183 19.4. Version -01 . . . . . . . . . . . . . . . . . . . . . . 185
19.4. Version -00 . . . . . . . . . . . . . . . . . . . . . . 184 19.5. Version -00 . . . . . . . . . . . . . . . . . . . . . . 185
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 184 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 185
20.1. Normative References . . . . . . . . . . . . . . . . . . 184 20.1. Normative References . . . . . . . . . . . . . . . . . . 185
20.2. Informative References . . . . . . . . . . . . . . . . . 185 20.2. Informative References . . . . . . . . . . . . . . . . . 187
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 186 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 187
1. Introduction 1. Introduction
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 Network Configuration Protocol state data manipulated by the Network Configuration Protocol
(NETCONF), NETCONF remote procedure calls, and NETCONF notifications. (NETCONF), NETCONF remote procedure calls, and NETCONF notifications.
YANG is used to model the operations and content layers of NETCONF YANG is used to model the operations and content layers of NETCONF
(see the NETCONF Configuration Protocol [RFC6241], Section 1.2). (see the NETCONF Configuration Protocol [RFC6241], Section 1.2).
This document describes the syntax and semantics of the YANG This document describes the syntax and semantics of the YANG
skipping to change at page 9, line 36 skipping to change at page 9, line 40
o Clarified the XPath context's tree in Section 6.4.1. o Clarified the XPath context's tree in Section 6.4.1.
o Defined the string value of an identityref in XPath expressions o Defined the string value of an identityref in XPath expressions
(see Section 9.10). (see Section 9.10).
o Clarified what unprefixed names means in leafrefs in typedefs (see o Clarified what unprefixed names means in leafrefs in typedefs (see
Section 9.9.2). Section 9.9.2).
o Allow identities to be derived from multiple base identities (see o Allow identities to be derived from multiple base identities (see
Section 7.16 and Section 9.10). Section 7.17 and Section 9.10).
o Allow enumerations to be subtyped (see Section 9.6). o Allow enumerations to be subtyped (see Section 9.6).
o Allow leaf-lists to have default values (see Section 7.7.2). o Allow leaf-lists to have default values (see Section 7.7.2).
o Use [RFC7405] syntax for case-sensitive strings in the grammar. o Use [RFC7405] syntax for case-sensitive strings in the grammar.
o Changed the module advertisement mechanism (see Section 5.6.4).
o Changed the scoping rules for definitions in submodules. A
submodule can now reference all defintions in all submodules that
belong to the same module, without using the "include" statement.
o Added a new statement "action" that is used to define operations
tied to data nodes.
2. Keywords 2. Keywords
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14, [RFC2119]. 14, [RFC2119].
3. Terminology 3. Terminology
o action: An operation defined for a node in the data tree.
o anyxml: A data node that can contain an unknown chunk of XML data. o anyxml: A data node that can contain an unknown chunk of XML data.
o augment: Adds new schema nodes to a previously defined schema o augment: Adds new schema nodes to a previously defined schema
node. node.
o base type: The type from which a derived type was derived, which o base type: The type from which a derived type was derived, which
may be either a built-in type or another derived type. may be either a built-in type or another derived type.
o built-in type: A YANG data type defined in the YANG language, such o built-in type: A YANG data type defined in the YANG language, such
as uint32 or string. as uint32 or string.
skipping to change at page 15, line 5 skipping to change at page 15, line 11
A NETCONF server may implement a number of modules, allowing multiple A NETCONF server may implement a number of modules, allowing multiple
views of the same data, or multiple views of disjoint subsections of views of the same data, or multiple views of disjoint subsections of
the device's data. Alternatively, the server may implement only one the device's data. Alternatively, the server may implement only one
module that defines all available data. module that defines all available data.
A module may be divided into submodules, based on the needs of the A module may be divided into submodules, based on the needs of the
module owner. The external view remains that of a single module, module owner. The external view remains that of a single module,
regardless of the presence or size of its submodules. regardless of the presence or size of its submodules.
The "include" statement allows a module or submodule to reference The "import" statement allows a module or submodule to reference
material in submodules, and the "import" statement allows references material defined in other modules.
to material defined in other modules.
The "include" statement is used by a module to incorporate the
contents of its submodules into the module.
4.2.2. Data Modeling Basics 4.2.2. Data Modeling Basics
YANG defines four types of nodes for data modeling. In each of the YANG defines four types of nodes for data modeling. In each of the
following subsections, the example shows the YANG syntax as well as a following subsections, the example shows the YANG syntax as well as a
corresponding NETCONF XML representation. corresponding NETCONF XML representation.
4.2.2.1. Leaf Nodes 4.2.2.1. Leaf Nodes
A leaf node contains simple data like an integer or a string. It has A leaf node contains simple data like an integer or a string. It has
skipping to change at page 24, line 31 skipping to change at page 24, line 31
NETCONF XML Example: NETCONF XML Example:
<user> <user>
<name>alicew</name> <name>alicew</name>
<full-name>Alice N. Wonderland</full-name> <full-name>Alice N. Wonderland</full-name>
<class>drop-out</class> <class>drop-out</class>
<other:uid>1024</other:uid> <other:uid>1024</other:uid>
</user> </user>
The "augment" statement is covered in Section 7.15. The "augment" statement is covered in Section 7.16.
4.2.9. RPC Definitions 4.2.9. Operation Definitions
YANG allows the definition of NETCONF RPCs. The operations' names, YANG allows the definition of operations. The operations' names,
input parameters, and output parameters are modeled using YANG data input parameters, and output parameters are modeled using YANG data
definition statements. definition statements. Operations on the top-level in a module are
defined with the "rpc" statement. Operations can also be tied to a
node in the data hierarchy. Such operations are defined with the
"action" statement.
YANG Example: YANG Example:
rpc activate-software-image { rpc activate-software-image {
input { input {
leaf image-name { leaf image-name {
type string; type string;
} }
} }
output { output {
skipping to change at page 25, line 21 skipping to change at page 25, line 34
</activate-software-image> </activate-software-image>
</rpc> </rpc>
<rpc-reply message-id="101" <rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<status xmlns="http://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>
</rpc-reply> </rpc-reply>
The "rpc" statement is covered in Section 7.13. The "rpc" statement is covered in Section 7.13, and the "action"
statement in Section 7.14.
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 {
skipping to change at page 26, line 15 skipping to change at page 26, line 32
<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> <if-admin-status>up</if-admin-status>
<if-oper-status>down</if-oper-status> <if-oper-status>down</if-oper-status>
</link-failure> </link-failure>
</notification> </notification>
The "notification" statement is covered in Section 7.14. The "notification" statement is covered in Section 7.15.
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.
Submodules are partial modules that contribute definitions to a Submodules are partial modules that contribute definitions to a
module. A module may include any number of submodules, but each module. A module may include any number of submodules, but each
submodule may belong to only one module. submodule may belong to only one module.
The names of all standard modules and submodules MUST be unique. The names of all standard modules and submodules MUST be unique.
Developers of enterprise modules are RECOMMENDED to choose names for Developers of enterprise modules are RECOMMENDED to choose names for
their modules that will have a low probability of colliding with their modules that will have a low probability of colliding with
standard or other enterprise modules, e.g., by using the enterprise standard or other enterprise modules, e.g., by using the enterprise
or organization name as a prefix for the module name. or organization name as a prefix for the module name.
A module uses the "include" statement to include its submodules, and A module uses the "include" statement to include all its submodules,
the "import" statement to reference external modules. Similarly, a and the "import" statement to reference external modules. Similarly,
submodule uses the "import" statement to reference other modules, and a submodule uses the "import" statement to reference other modules.
uses the "include" statement to reference other submodules within its
module. A module or submodule MUST NOT include submodules from other For backwards compatibility with YANG version 1, a submodule is
modules, and a submodule MUST NOT import its own module. allowed it use the "include" statement to reference other submodules
within its module, but this is not necessary in YANG version 1.1. A
submodule can reference any definition in the module it belongs to
and in all submodules included by the module.
A module or submodule MUST NOT include submodules from other modules,
and a submodule MUST NOT import its own module.
The import and include statements are used to make definitions The import and include statements are used to make definitions
available to other modules and submodules: available from other modules:
o For a module or submodule to reference definitions in an external o For a module or submodule to reference definitions in an external
module, the external module MUST be imported. module, the external module MUST be imported.
o For a module to reference definitions in one of its submodules, o A module MUST include all its submodules.
the module MUST include the submodule.
o For a submodule to reference definitions in a second submodule of o A module or submodule belonging to that module can reference
the same module, the first submodule MUST include the second definitions in the module and all submodules included by the
submodule. module.
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 module "a" imports module "b", "b" cannot import "a".
"a".
When a definition in an external module is referenced, a locally When a definition in an external module is referenced, a locally
defined prefix MUST be used, followed by ":", and then the external defined prefix MUST be used, followed by ":", and then the external
identifier. References to definitions in the local module MAY use identifier. References to definitions in the local module MAY use
the prefix notation. Since built-in data types do not belong to any the prefix notation. Since built-in data types do not belong to any
module and have no prefix, references to built-in data types (e.g., module and have no prefix, references to built-in data types (e.g.,
int32) cannot use the prefix notation. int32) cannot use the prefix notation. The syntax for a reference to
a definition is formally defined by the rule "identifier-ref" in
Section 13.
5.1.1. Import and Include by Revision 5.1.1. Import and Include by Revision
Published modules evolve independently over time. In order to allow Published modules evolve independently over time. In order to allow
for this evolution, modules need to be imported using specific for this evolution, modules need to be imported using specific
revisions. When a module is written, it uses the current revisions revisions. When a module is written, it uses the current revisions
of other modules, based on what is available at the time. As future of other modules, based on what is available at the time. As future
revisions of the imported modules are published, the importing module revisions of the imported modules are published, the importing module
is unaffected and its contents are unchanged. When the author of the is unaffected and its contents are unchanged. When the author of the
module is prepared to move to the most recently published revision of module is prepared to move to the most recently published revision of
skipping to change at page 30, line 21 skipping to change at page 30, line 27
Namespaces for private modules are assigned by the organization Namespaces for private modules are assigned by the organization
owning the module without a central registry. Namespace URIs MUST be owning the module without a central registry. Namespace URIs MUST be
chosen so they cannot collide with standard or other enterprise chosen so they cannot collide with standard or other enterprise
namespaces, for example by using the enterprise or organization name namespaces, for example by using the enterprise or organization name
in the namespace. in the namespace.
The "namespace" statement is covered in Section 7.1.3. The "namespace" statement is covered in Section 7.1.3.
5.3.1. YANG XML Namespace 5.3.1. YANG XML Namespace
YANG defines an XML namespace for NETCONF <edit-config> operations YANG defines an XML namespace for NETCONF <edit-config> operations,
and <error-info> content. The name of this namespace is <error-info> content, and the <action> element. The name of this
"urn:ietf:params:xml:ns:yang:1". namespace is "urn:ietf:params:xml:ns:yang:1".
5.4. Resolving Grouping, Type, and Identity Names 5.4. Resolving Grouping, Type, and Identity Names
Grouping, type, and identity names are resolved in the context in Grouping, type, and identity names are resolved in the context in
which they are defined, rather than the context in which they are which they are defined, rather than the context in which they are
used. Users of groupings, typedefs, and identities are not required used. Users of groupings, typedefs, and identities are not required
to import modules or include submodules to satisfy all references to import modules or include submodules to satisfy all references
made by the original definition. This behaves like static scoping in made by the original definition. This behaves like static scoping in
a conventional programming language. a conventional programming language.
skipping to change at page 32, line 36 skipping to change at page 32, line 43
strings, and may make portions of the module optional based on those strings, and may make portions of the module optional based on those
features. If the device supports a feature, then the corresponding features. If the device supports a feature, then the corresponding
portions of the module are valid for that device. If the device 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, doesn't support the feature, those parts of the module are not valid,
and applications should behave accordingly. and applications should behave accordingly.
Features are defined using the "feature" statement. Definitions in Features are defined using the "feature" statement. Definitions in
the module that are conditional to the feature are noted by the the module that are conditional to the feature are noted by the
"if-feature" statement. "if-feature" statement.
Further details are available in Section 7.18.1. Further details are available in Section 7.19.1.
5.6.3. Deviations 5.6.3. Deviations
In an ideal world, all devices would be required to implement the In an ideal world, all devices would be required to implement the
model exactly as defined, and deviations from the model would not be model exactly as defined, and deviations from the model would not be
allowed. But in the real world, devices are often not able or allowed. But in the real world, devices are often not able or
designed to implement the model as written. For YANG-based designed to implement the model as written. For YANG-based
automation to deal with these device deviations, a mechanism must automation to deal with these device deviations, a mechanism must
exist for devices to inform applications of the specifics of such exist for devices to inform applications of the specifics of such
deviations. deviations.
skipping to change at page 33, line 13 skipping to change at page 33, line 21
would be far better if the application had prior knowledge of this would be far better if the application had prior knowledge of this
limitation and could prevent the user from starting down the path limitation and could prevent the user from starting down the path
that could not succeed. that could not succeed.
Device deviations are declared using the "deviation" statement, which Device deviations are declared using the "deviation" statement, which
takes as its argument a string that identifies a node in the schema takes as its argument a string that identifies a node in the schema
tree. The contents of the statement details the manner in which the tree. The contents of the statement details the manner in which the
device implementation deviates from the contract as defined in the device implementation deviates from the contract as defined in the
module. module.
Further details are available in Section 7.18.3. Further details are available in Section 7.19.3.
5.6.4. Announcing Conformance Information in the <hello> Message 5.6.4. Announcing Conformance Information in the <hello> Message
The namespace URI MUST be advertised as a capability in the NETCONF This document defines the following mechanism for announcing
<hello> message to indicate support for the YANG module by a NETCONF conformance information. Other mechanisms may be defined by future
server. The capability URI advertised MUST be of the form: specificiations.
capability-string = namespace-uri [ parameter-list ]
parameter-list = "?" parameter *( "&" parameter )
parameter = revision-parameter /
module-parameter /
feature-parameter /
deviation-parameter
revision-parameter = "revision=" revision-date
module-parameter = "module=" module-name
feature-parameter = "features=" feature *( "," feature )
deviation-parameter = "deviations=" deviation *( "," deviation )
Where "revision-date" is the revision of the module (see
Section 7.1.9) that the NETCONF 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 URI for the module as
it appears in the "namespace" statement (see Section 7.1.3),
"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).
In the parameter list, each named parameter MUST occur at most once.
5.6.4.1. Modules
Servers indicate the names of supported modules via the <hello>
message. Module namespaces are encoded as the base URI in the
capability string, and the module name is encoded as the "module"
parameter to the base URI.
A server MUST advertise all revisions of all modules it implements.
For example, this <hello> message advertises one module "syslog".
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<!-- wrapped for display only -->
<capability>
http://example.com/syslog?module=syslog&amp;
revision=2008-04-01
</capability>
</capabilities>
<session-id>42</session-id>
</hello>
5.6.4.2. Features
Servers indicate the names of supported features 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 that the device supports for
the specific module.
For example, this <hello> message advertises one module, informing
the client that it supports the "local-storage" feature of module
"syslog".
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<!-- wrapped for display only -->
<capability>
http://example.com/syslog?module=syslog&amp;
features=local-storage
</capability>
</capabilities>
<session-id>43</session-id>
</hello>
5.6.4.3. Deviations A NETCONF server announces the modules it implements by implementing
the YANG module "ietf-yang-library" defined in
[I-D.ietf-netconf-yang-library]. The server also advertises the
following capability in the <hello> message (line-breaks and
whitespaces are used for formatting reasons only):
Device deviations are announced via the "deviations" parameter. The urn:ietf:params:netconf:capability:yang-library:1.0?
value of the "deviations" parameter is a comma-separated list of module-set-id=<id>
modules containing deviations from the capability's module.
For example, this <hello> message advertises two modules, informing The parameter "module-set-id" has the same value as the leaf
the client that it deviates from module "syslog" according to the "/modules/module-set-id" from "ietf-yang-library". This parameter
deviations listed in the module "my-devs". MUST be present.
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> With this mechanism, a client can cache the supported modules for a
<capabilities> server, and only update the cache if the "module-set-id" value in the
<!-- wrapped for display only --> <hello> message changes.
<capability>
http://example.com/syslog?module=syslog&amp;
deviations=my-devs
</capability>
<capability>
http://example.com/my-deviations?module=my-devs
</capability>
</capabilities>
<session-id>44</session-id>
</hello>
5.7. Data Store Modification 5.7. Data Store Modification
Data models may allow the server to alter the configuration data Data models may allow the server to alter the configuration data
store in ways not explicitly directed via NETCONF protocol messages. store in ways not explicitly directed via NETCONF protocol messages.
For example, a data model may define leafs that are assigned system- For example, a data model may define leafs that are assigned system-
generated values when the client does not provide one. A formal generated values when the client does not provide one. A formal
mechanism for specifying the circumstances where these changes are mechanism for specifying the circumstances where these changes are
allowed is out of scope for this specification. allowed is out of scope for this specification.
skipping to change at page 39, line 19 skipping to change at page 37, line 46
either by a semicolon (";") or a block of substatements enclosed either by a semicolon (";") or a block of substatements enclosed
within braces ("{ }"): within 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.17). The extensions can be imported by other keyword (see Section 7.18). 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 that 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.
If a YANG compiler does not support a particular extension, which If a YANG compiler does not support a particular extension, which
appears in a YANG module as an unknown-statement (see Section 13), appears in a YANG module as an unknown-statement (see Section 13),
the entire unknown-statement MAY be ignored by the compiler. the entire unknown-statement MAY be ignored by the compiler.
6.4. XPath Evaluations 6.4. XPath Evaluations
YANG relies on XML Path Language (XPath) 1.0 [XPATH] as a notation YANG relies on XML Path Language (XPath) 1.0 [XPATH] as a notation
for specifying many inter-node references and dependencies. NETCONF for specifying many inter-node references and dependencies. NETCONF
clients and servers are not required to implement an XPath clients and servers are not required to implement an XPath
interpreter, but MUST ensure that the requirements encoded in the interpreter, but MUST ensure that the requirements encoded in the
skipping to change at page 40, line 5 skipping to change at page 38, line 27
correct, and all prefixes used MUST be present in the XPath context correct, and all prefixes used MUST be present in the XPath context
(see Section 6.4.1). An implementation may choose to implement them (see Section 6.4.1). An implementation may choose to implement them
by hand, rather than using the XPath expression directly. by hand, rather than using the XPath expression directly.
The data model used in the XPath expressions is the same as that used The data model used in the XPath expressions is the same as that used
in XPath 1.0 [XPATH], with the same extension for root node children in XPath 1.0 [XPATH], with the same extension for root node children
as used by XSLT 1.0 [XSLT] (Section 3.1). Specifically, it means as used by XSLT 1.0 [XSLT] (Section 3.1). Specifically, it means
that the root node may have any number of element nodes as its that the root node may have any number of element nodes as its
children. children.
Numbers in XPath 1.0 are IEEE 754 double-precision floating-point
values, see Section 3.5 in [XPATH]. This means that some values of
int64, uint64 and decimal64 types (see Section 9.2 and Section 9.3)
cannot be exactly represented in XPath expressions. Therefore, due
caution should be exercised when using nodes with 64-bit numeric
values in XPath expressions. In particular, numerical comparisons
involving equality may yield unexpected results.
For example, consider the following definition:
leaf lxiv {
type decimal64 {
fraction-digits 18;
}
must ". <= 10";
}
An instance of the "lxiv" leaf having the value of
10.0000000000000001 will then successfully pass validation.
6.4.1. XPath Context 6.4.1. XPath Context
All YANG XPath expressions share the following XPath context All YANG XPath expressions share the following XPath context
definition: definition:
o The set of namespace declarations is the set of all "import" o The set of namespace declarations is the set of all "import"
statements' prefix and namespace pairs in the module where the statements' prefix and namespace pairs in the module where the
XPath expression is specified, and the "prefix" statement's prefix XPath expression is specified, and the "prefix" statement's prefix
for the "namespace" statement's URI. for the "namespace" statement's URI.
skipping to change at page 44, line 8 skipping to change at page 43, line 8
// module definitions // module definitions
<other statements> <other 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.16 | 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.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| deviation | 7.18.3 | 0..n | | deviation | 7.19.3 | 0..n |
| extension | 7.17 | 0..n | | extension | 7.18 | 0..n |
| feature | 7.18.1 | 0..n | | feature | 7.19.1 | 0..n |
| grouping | 7.11 | 0..n | | grouping | 7.11 | 0..n |
| identity | 7.16 | 0..n | | identity | 7.17 | 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.15 | 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.19.4 | 0..1 | | reference | 7.20.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 | 1 | | yang-version | 7.1.2 | 1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.1.2. The yang-version Statement 7.1.2. The yang-version Statement
The "yang-version" statement specifies which version of the YANG The "yang-version" statement specifies which version of the YANG
skipping to change at page 46, line 48 skipping to change at page 45, line 48
7.1.5.1. The import's revision-date Statement 7.1.5.1. The import's revision-date Statement
The import's "revision-date" statement is used to specify the exact The import's "revision-date" statement is used to specify the exact
version of the module to import. The "revision-date" statement MUST version of the module to import. The "revision-date" statement MUST
match the most recent "revision" statement in the imported module. match the most recent "revision" statement in the imported module.
7.1.6. The include Statement 7.1.6. The include Statement
The "include" statement is used to make content from a submodule The "include" statement is used to make content from a submodule
available to that submodule's parent module, or to another submodule available to that submodule's parent module. The argument is an
of that parent module. The argument is an identifier that is the identifier that is the name of the submodule to include. Modules are
name of the submodule to include. Modules are only allowed to only allowed to include submodules that belong to that module, as
include submodules that belong to that module, as defined by the defined by the "belongs-to" statement (see Section 7.2.2).
"belongs-to" statement (see Section 7.2.2). Submodules are only
allowed to include other submodules belonging to the same module. Submodules are only allowed to include other submodules belonging to
the same module.
When a module includes a submodule, it incorporates the contents of When a module includes a submodule, it incorporates the contents of
the submodule into the node hierarchy of the module. When a the submodule into the node hierarchy of the module.
submodule includes another submodule, the target submodule's
definitions are made available to the current submodule. For backwards compatibility with YANG version 1, a submodule is
allowed to include another submodule belonging to the same module,
but this is not necessary in YANG version 1.1.
When the optional "revision-date" substatement is present, the When the optional "revision-date" substatement is present, the
specified revision of the submodule is included in the module. It is specified revision of the submodule is included in the module. It is
an error if the specified revision of the submodule does not exist. an error if the specified revision of the submodule does not exist.
If no "revision-date" substatement is present, it is undefined which If no "revision-date" substatement is present, it is undefined which
revision of the submodule is included. revision of the submodule is included.
Multiple revisions of the same submodule MUST NOT be included. Multiple revisions of the same submodule MUST NOT be included.
+---------------+---------+-------------+ +---------------+---------+-------------+
skipping to change at page 48, line 12 skipping to change at page 47, line 14
module SHOULD have at least one "revision" statement. For every module SHOULD have at least one "revision" statement. For every
published editorial change, a new one SHOULD be added in front of the published 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.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| reference | 7.19.4 | 0..1 | | reference | 7.20.4 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.1.10. Usage Example 7.1.10. Usage Example
module acme-system { module acme-system {
yang-version 1.1; yang-version 1.1;
namespace "http://acme.example.com/system"; namespace "http://acme.example.com/system";
prefix "acme"; prefix "acme";
import ietf-yang-types { import ietf-yang-types {
skipping to change at page 50, line 9 skipping to change at page 49, line 9
A submodule typically has the following layout: A submodule typically has the following layout:
submodule <module-name> { submodule <module-name> {
<yang-version statement> <yang-version statement>
// module identification // module identification
<belongs-to statement> <belongs-to statement>
// linkage statements // linkage statements
<import statements> <import statements>
<include statements>
// meta information // meta information
<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
<other statements> <other 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.16 | 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.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| deviation | 7.18.3 | 0..n | | deviation | 7.19.3 | 0..n |
| extension | 7.17 | 0..n | | extension | 7.18 | 0..n |
| feature | 7.18.1 | 0..n | | feature | 7.19.1 | 0..n |
| grouping | 7.11 | 0..n | | grouping | 7.11 | 0..n |
| identity | 7.16 | 0..n | | identity | 7.17 | 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.15 | 0..n |
| organization | 7.1.7 | 0..1 | | organization | 7.1.7 | 0..1 |
| reference | 7.19.4 | 0..1 | | reference | 7.20.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 | 1 | | yang-version | 7.1.2 | 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 that is the name of submodule belongs. The argument is an identifier that is the name of
the module. the module.
A submodule MUST only be included by the module to which it belongs, A submodule MUST only be included by the module to which it belongs,
or by another submodule that belongs to that module. or by another submodule that belongs to that module.
The mandatory "prefix" substatement assigns a prefix for the module The mandatory "prefix" substatement assigns a prefix for the module
to which the submodule belongs. All definitions in the local to which the submodule belongs. All definitions in the module that
submodule and any included submodules can be accessed by using the the submodule belongs to and all its submodules can be accessed by
prefix. using the prefix.
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| prefix | 7.1.4 | 1 | | prefix | 7.1.4 | 1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
The belongs-to's Substatements The belongs-to's Substatements
7.2.3. Usage Example 7.2.3. Usage Example
skipping to change at page 52, line 50 skipping to change at page 51, line 50
revision "2007-06-09" { revision "2007-06-09" {
description "Initial revision."; description "Initial revision.";
} }
// definitions follows... // definitions follows...
} }
7.3. The typedef Statement 7.3. The typedef Statement
The "typedef" statement defines a new type that may be used locally The "typedef" statement defines a new type that may be used locally
in the module, in modules or submodules which include it, and by in the module or submodule, and by other modules that import from it,
other modules that import from it, according to the rules in according to the rules in Section 5.5. The new type is called the
Section 5.5. The new type is called the "derived type", and the type "derived type", and the type from which it was derived is called the
from which it was derived is called the "base type". All derived "base type". All derived types can be traced back to a YANG built-in
types can be traced back to a YANG built-in type. type.
The "typedef" statement's argument is an identifier that is the name The "typedef" statement's argument is an identifier that is the name
of the type to be defined, and MUST be followed by a block of of the type to be defined, and MUST be followed by a block of
substatements that holds detailed typedef information. substatements that holds detailed typedef information.
The name of the type MUST NOT be one of the YANG built-in types. If The name of the type MUST NOT be one of the YANG built-in types. If
the typedef is defined at the top level of a YANG module or the typedef is defined at the top level of a YANG module or
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. the module.
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.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| reference | 7.19.4 | 0..1 | | reference | 7.20.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.20.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 54, line 33 skipping to change at page 53, line 33
The restrictions that can be applied depend on the type being The restrictions that can be applied depend on the type being
restricted. The restriction statements for all built-in types are restricted. The restriction statements for all built-in types are
described in the subsections of Section 9. described in the subsections of Section 9.
7.4.1. The type's Substatements 7.4.1. The type's Substatements
+------------------+---------+-------------+ +------------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+------------------+---------+-------------+ +------------------+---------+-------------+
| base | 7.16.2 | 0..n | | base | 7.17.2 | 0..n |
| bit | 9.7.4 | 0..n | | bit | 9.7.4 | 0..n |
| enum | 9.6.4 | 0..n | | enum | 9.6.4 | 0..n |
| fraction-digits | 9.3.4 | 0..1 | | fraction-digits | 9.3.4 | 0..1 |
| length | 9.4.4 | 0..1 | | length | 9.4.4 | 0..1 |
| path | 9.9.2 | 0..1 | | path | 9.9.2 | 0..1 |
| pattern | 9.4.5 | 0..n | | pattern | 9.4.5 | 0..n |
| range | 9.2.4 | 0..1 | | range | 9.2.4 | 0..1 |
| require-instance | 9.9.3 | 0..1 | | require-instance | 9.9.3 | 0..1 |
| type | 7.4 | 0..n | | type | 7.4 | 0..n |
+------------------+---------+-------------+ +------------------+---------+-------------+
skipping to change at page 56, line 7 skipping to change at page 55, line 7
the device using ssh, but can also contain any ssh-related the device using ssh, but can also contain any ssh-related
configuration knobs, such as connection rates or retry limits. configuration knobs, such as connection rates or retry limits.
The "presence" statement (see Section 7.5.5) is used to give The "presence" statement (see Section 7.5.5) is used to give
semantics to the existence of the container in the data tree. semantics to the existence of the container in the data tree.
7.5.2. The container's Substatements 7.5.2. The container's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| action | 7.14 | 0..n |
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| config | 7.19.1 | 0..1 | | config | 7.20.1 | 0..1 |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| grouping | 7.11 | 0..n | | grouping | 7.11 | 0..n |
| if-feature | 7.18.2 | 0..n | | if-feature | 7.19.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.3 | 0..n | | must | 7.5.3 | 0..n |
| presence | 7.5.5 | 0..1 | | presence | 7.5.5 | 0..1 |
| reference | 7.19.4 | 0..1 | | reference | 7.20.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.20.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 | | when | 7.20.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.5.3. The must Statement 7.5.3. 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 that contains an XPath expression (see Section 6.4). It is string that contains an XPath expression (see Section 6.4). It is
used to formally declare a constraint on valid data. The constraint used to formally declare a constraint on valid data. The constraint
is enforced according to the rules in Section 8. is enforced according to the rules in Section 8.
When a datastore is validated, all "must" constraints are When a datastore is validated, all "must" constraints are
skipping to change at page 57, line 15 skipping to change at page 56, line 15
Also note that the XPath expression is conceptually evaluated. This Also note that the XPath expression is conceptually evaluated. This
means that an implementation does not have to use an XPath evaluator means that an implementation does not have to use an XPath evaluator
on the device. How the evaluation is done in practice is an on the device. How the evaluation is done in practice is an
implementation decision. implementation decision.
7.5.4. The must's Substatements 7.5.4. The must's Substatements
+---------------+---------+-------------+ +---------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+---------------+---------+-------------+ +---------------+---------+-------------+
| description | 7.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| error-app-tag | 7.5.4.2 | 0..1 | | error-app-tag | 7.5.4.2 | 0..1 |
| error-message | 7.5.4.1 | 0..1 | | error-message | 7.5.4.1 | 0..1 |
| reference | 7.19.4 | 0..1 | | reference | 7.20.4 | 0..1 |
+---------------+---------+-------------+ +---------------+---------+-------------+
7.5.4.1. The error-message Statement 7.5.4.1. The error-message Statement
The "error-message" statement, which is optional, takes a string as The "error-message" statement, which is optional, takes a string as
an argument. If the constraint evaluates to false, the string is an argument. If the constraint evaluates to false, the string is
passed as <error-message> in the <rpc-error>. passed as <error-message> in the <rpc-error>.
7.5.4.2. The error-app-tag Statement 7.5.4.2. The error-app-tag Statement
skipping to change at page 61, line 40 skipping to change at page 60, line 40
value of the "default" statement. Otherwise, if the leaf's type has value of the "default" statement. Otherwise, if the leaf's type has
a default value, and the leaf is not mandatory, then the leaf's a default value, and the leaf is not mandatory, then the leaf's
default value is the type's default value. In all other cases, the default value is the type's default value. In all other cases, the
leaf does not have a default value. leaf does not have a default value.
7.6.2. The leaf's Substatements 7.6.2. The leaf's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| config | 7.19.1 | 0..1 | | config | 7.20.1 | 0..1 |
| default | 7.6.4 | 0..1 | | default | 7.6.4 | 0..1 |
| description | 7.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| if-feature | 7.18.2 | 0..n | | if-feature | 7.19.2 | 0..n |
| mandatory | 7.6.5 | 0..1 | | mandatory | 7.6.5 | 0..1 |
| must | 7.5.3 | 0..n | | must | 7.5.3 | 0..n |
| reference | 7.19.4 | 0..1 | | reference | 7.20.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.20.2 | 0..1 |
| type | 7.6.3 | 1 | | type | 7.6.3 | 1 |
| units | 7.3.3 | 0..1 | | units | 7.3.3 | 0..1 |
| when | 7.19.5 | 0..1 | | when | 7.20.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.6.3. The leaf's type Statement 7.6.3. 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.4. The leaf's default Statement 7.6.4. The leaf's default Statement
skipping to change at page 66, line 13 skipping to change at page 65, line 13
a default value, and the leaf-list does not have a "min-elements" a default value, and the leaf-list does not have a "min-elements"
statement with a value greater than or equal to one, then the leaf- statement with a value greater than or equal to one, then the leaf-
list's default value is the type's default value. In all other list's default value is the type's default value. In all other
cases, the leaf-list does not have any default values. cases, the leaf-list does not have any default values.
7.7.3. The leaf-list's Substatements 7.7.3. The leaf-list's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| config | 7.19.1 | 0..1 | | config | 7.20.1 | 0..1 |
| default | 7.7.4 | 0..n | | default | 7.7.4 | 0..n |
| description | 7.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| if-feature | 7.18.2 | 0..n | | if-feature | 7.19.2 | 0..n |
| max-elements | 7.7.6 | 0..1 | | max-elements | 7.7.6 | 0..1 |
| min-elements | 7.7.5 | 0..1 | | min-elements | 7.7.5 | 0..1 |
| must | 7.5.3 | 0..n | | must | 7.5.3 | 0..n |
| ordered-by | 7.7.7 | 0..1 | | ordered-by | 7.7.7 | 0..1 |
| reference | 7.19.4 | 0..1 | | reference | 7.20.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.20.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 | | when | 7.20.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.7.4. The leaf-list's default Statement 7.7.4. The leaf-list's default Statement
The "default" statement, which is optional, takes as an argument a The "default" statement, which is optional, takes as an argument a
string that contains a default value for the leaf-list. string that contains a default value for the leaf-list.
The value of the "default" statement MUST be valid according to the The value of the "default" statement MUST be valid according to the
type specified in the leaf-list's "type" statement. type specified in the leaf-list's "type" statement.
skipping to change at page 72, line 7 skipping to change at page 71, line 7
statement takes one argument, which is an identifier, followed by a statement takes one argument, which is an identifier, followed by a
block of substatements that holds detailed list information. block of 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,
if defined. if defined.
7.8.1. The list's Substatements 7.8.1. The list's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| action | 7.14 | 0..n |
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| config | 7.19.1 | 0..1 | | config | 7.20.1 | 0..1 |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| grouping | 7.11 | 0..n | | grouping | 7.11 | 0..n |
| if-feature | 7.18.2 | 0..n | | if-feature | 7.19.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.6 | 0..1 | | max-elements | 7.7.6 | 0..1 |
| min-elements | 7.7.5 | 0..1 | | min-elements | 7.7.5 | 0..1 |
| must | 7.5.3 | 0..n | | must | 7.5.3 | 0..n |
| ordered-by | 7.7.7 | 0..1 | | ordered-by | 7.7.7 | 0..1 |
| reference | 7.19.4 | 0..1 | | reference | 7.20.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.20.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 | | when | 7.20.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.8.2. The list's key Statement 7.8.2. The list's key Statement
The "key" statement, which MUST be present if the list represents The "key" statement, which MUST be present if the list represents
configuration, and MAY be present otherwise, takes as an argument a configuration, and MAY be present otherwise, takes as an argument a
string that specifies a space-separated list of leaf identifiers of string that specifies a space-separated list of 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. The leafs can be defined directly in substatements to the list. The leafs can be defined directly in substatements to the
skipping to change at page 80, line 10 skipping to change at page 79, line 10
See Section 8.3.2 for additional information. See Section 8.3.2 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 |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| config | 7.19.1 | 0..1 | | config | 7.20.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.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| if-feature | 7.18.2 | 0..n | | if-feature | 7.19.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.19.4 | 0..1 | | reference | 7.20.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.20.2 | 0..1 |
| when | 7.19.5 | 0..1 | | when | 7.20.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 81, line 29 skipping to change at page 80, 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 |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| if-feature | 7.18.2 | 0..n | | if-feature | 7.19.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.19.4 | 0..1 | | reference | 7.20.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.20.2 | 0..1 |
| uses | 7.12 | 0..n | | uses | 7.12 | 0..n |
| when | 7.19.5 | 0..1 | | when | 7.20.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.9.3. The choice's default Statement 7.9.3. The choice's default Statement
The "default" statement indicates if a case should be considered as The "default" statement indicates if a case should be considered as
the default if no child nodes from any of the choice's cases exist. the default if no child nodes from any of the choice's cases exist.
The argument is the identifier of the "case" statement. If the The argument is the identifier of the "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
skipping to change at page 85, line 7 skipping to change at page 84, line 7
The "anyxml" statement defines an interior node in the schema tree. The "anyxml" statement defines an interior node in the schema tree.
It takes one argument, which is an identifier, followed by a block of It takes one argument, which is an identifier, followed by a block of
substatements that holds detailed anyxml information. substatements that holds detailed anyxml information.
The "anyxml" statement is used to represent an unknown chunk of XML. The "anyxml" statement is used to represent an unknown chunk of XML.
No restrictions are placed on the XML. This can be useful, for No restrictions are placed on the XML. This can be useful, for
example, in RPC replies. An example is the <filter> parameter in the example, in RPC replies. An example is the <filter> parameter in the
<get-config> operation. <get-config> operation.
An anyxml node cannot be augmented (see Section 7.15). An anyxml node cannot be augmented (see Section 7.16).
Since the use of anyxml limits the manipulation of the content, it is Since the use of anyxml limits the manipulation of the content, it is
RECOMMENDED that the "anyxml" statement not be used to represent RECOMMENDED that the "anyxml" statement not be used to represent
configuration data. configuration data.
An anyxml node exists in zero or one instances in the data tree. An anyxml node exists in zero or one instances in the data tree.
7.10.1. The anyxml's Substatements 7.10.1. The anyxml's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| config | 7.19.1 | 0..1 | | config | 7.20.1 | 0..1 |
| description | 7.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| if-feature | 7.18.2 | 0..n | | if-feature | 7.19.2 | 0..n |
| mandatory | 7.6.5 | 0..1 | | mandatory | 7.6.5 | 0..1 |
| must | 7.5.3 | 0..n | | must | 7.5.3 | 0..n |
| reference | 7.19.4 | 0..1 | | reference | 7.20.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.20.2 | 0..1 |
| when | 7.19.5 | 0..1 | | when | 7.20.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.10.2. XML Mapping Rules 7.10.2. XML Mapping Rules
An anyxml node is encoded as an XML element. The element's local An anyxml node is encoded as an XML element. The element's local
name is the anyxml's identifier, and its namespace is the module's name is the anyxml's identifier, and its namespace is the module's
XML namespace (see Section 7.1.3). The value of the anyxml node is XML namespace (see Section 7.1.3). The value of the anyxml node is
encoded as XML content of this element. encoded as XML content of 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 86, line 40 skipping to change at page 85, line 40
<data> <data>
<interface xmlns="http://example.com/ns/interface"> <interface xmlns="http://example.com/ns/interface">
<ifIndex>1</ifIndex> <ifIndex>1</ifIndex>
</interface> </interface>
</data> </data>
7.11. The grouping Statement 7.11. The grouping Statement
The "grouping" statement is used to define a reusable block of nodes, The "grouping" statement is used to define a reusable block of nodes,
which may be used locally in the module, in modules that include it, which may be used locally in the module or submodule, and by other
and by other modules that import from it, according to the rules in modules that import from it, according to the rules in Section 5.5.
Section 5.5. It takes one argument, which is an identifier, followed It takes one argument, which is an identifier, followed by a block of
by a block of substatements that holds detailed grouping information. substatements that holds detailed grouping information.
The "grouping" statement is not a data definition statement and, as The "grouping" statement is not a data definition statement and, as
such, does not define any nodes in the schema tree. such, does not define any nodes in the schema tree.
A grouping is like a "structure" or a "record" in conventional A grouping is like a "structure" or a "record" in conventional
programming languages. programming languages.
Once a grouping is defined, it can be referenced in a "uses" Once a grouping is defined, it can be referenced in a "uses"
statement (see Section 7.12). A grouping MUST NOT reference itself, statement (see Section 7.12). A grouping MUST NOT reference itself,
neither directly nor indirectly through a chain of other groupings. neither directly nor indirectly through a chain of other groupings.
skipping to change at page 87, line 26 skipping to change at page 86, line 26
defined, not where it is used. Prefix mappings, type names, grouping defined, not where it is used. Prefix mappings, type names, grouping
names, and extension usage are evaluated in the hierarchy where the names, and extension usage are evaluated in the hierarchy where the
"grouping" statement appears. For extensions, this means that "grouping" statement appears. For extensions, this means that
extensions are applied to the grouping node, not the uses node. extensions are applied to the grouping node, not the uses node.
7.11.1. The grouping's Substatements 7.11.1. The grouping's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| action | 7.14 | 0..n |
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 | | description | 7.20.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.19.4 | 0..1 | | reference | 7.20.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.20.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 ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
} }
grouping endpoint { grouping endpoint {
skipping to change at page 88, line 37 skipping to change at page 87, line 37
The identifiers defined in the grouping are not bound to a namespace The identifiers defined in the grouping are not bound to a namespace
until the contents of the grouping are added to the schema tree via a until the contents of the grouping are added to the schema tree via a
"uses" statement that does not appear inside a "grouping" statement, "uses" statement that does not appear inside a "grouping" statement,
at which point they are bound to the namespace of the current module. at which point they are bound to the namespace of the current module.
7.12.1. The uses's Substatements 7.12.1. The uses's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| augment | 7.15 | 0..n | | augment | 7.16 | 0..n |
| description | 7.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| if-feature | 7.18.2 | 0..n | | if-feature | 7.19.2 | 0..n |
| refine | 7.12.2 | 0..n | | refine | 7.12.2 | 0..n |
| reference | 7.19.4 | 0..1 | | reference | 7.20.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.20.2 | 0..1 |
| when | 7.19.5 | 0..1 | | when | 7.20.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.12.2. The refine Statement 7.12.2. The refine Statement
Some of the properties of each node in the grouping can be refined Some of the properties of each node in the grouping can be refined
with the "refine" statement. The argument is a string that with the "refine" statement. The argument is a string that
identifies a node in the grouping. This node is called the refine's identifies a node in the grouping. This node is called the refine's
target node. If a node in the grouping is not present as a target target node. If a node in the grouping is not present as a target
node of a "refine" statement, it is not refined, and thus used node of a "refine" statement, it is not refined, and thus used
exactly as it was defined in the grouping. exactly as it was defined in the grouping.
skipping to change at page 91, line 14 skipping to change at page 90, line 14
container http-server { container http-server {
uses acme:endpoint; uses acme:endpoint;
leaf ip { // illegal - same identifier "ip" used twice leaf ip { // illegal - same identifier "ip" used twice
type string; type string;
} }
} }
7.13. The rpc Statement 7.13. The rpc Statement
The "rpc" statement is used to define a NETCONF RPC operation. It The "rpc" statement is used to define an RPC operation. It takes one
takes one argument, which is an identifier, followed by a block of argument, which is an identifier, followed by a block of
substatements that holds detailed rpc information. This argument is substatements that holds detailed rpc information. This argument is
the name of the RPC, and is used as the element name directly under the name of the RPC, and is used as the element name directly under
the <rpc> element, as designated by the substitution group the <rpc> element, as designated by the substitution group
"rpcOperation" in [RFC6241]. "rpcOperation" in [RFC6241].
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, a schema node with the name "input", and a schema node the rpc node, a schema node with the name "input", and a schema 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.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| grouping | 7.11 | 0..n | | grouping | 7.11 | 0..n |
| if-feature | 7.18.2 | 0..n | | if-feature | 7.19.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.19.4 | 0..1 | | reference | 7.20.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.20.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 operation. It does not take an argument. The parameters to the operation. It does not take an argument. The
substatements to "input" define nodes under the RPC's input node. substatements to "input" define nodes under the operation's input
node.
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.
Otherwise, the server MUST return a "missing-element" error. Otherwise, the server MUST return a "missing-element" error.
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 use this value in the same cases as described in Section 7.6.1. MUST use this value in the same cases as described in Section 7.6.1.
In these cases, the server MUST operationally behave as if the leaf In these cases, the server MUST operationally behave as if the leaf
was present in the NETCONF RPC invocation with the default value as was present in the NETCONF RPC invocation with the default value as
its value. its value.
If a leaf-list in the input tree has one or more default values, the If a leaf-list in the input tree has one or more default values, the
NETCONF server MUST use these values in the same cases as described NETCONF server MUST use these values in the same cases as described
in Section 7.7.2. In these cases, the server MUST operationally in Section 7.7.2. In these cases, the server MUST operationally
behave as if the leaf-list was present in the NETCONF RPC invocation behave as if the leaf-list was present in the NETCONF RPC invocation
with the default values as its values. with the default values as its values.
skipping to change at page 92, line 42 skipping to change at page 91, line 44
| list | 7.8 | 0..n | | list | 7.8 | 0..n |
| must | 7.5.3 | 0..n | | must | 7.5.3 | 0..n |
| typedef | 7.3 | 0..n | | typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n | | uses | 7.12 | 0..n |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.13.3. The output Statement 7.13.3. The output Statement
The "output" statement, which is optional, is used to define output The "output" statement, which is optional, is used to define output
parameters to the RPC operation. It does not take an argument. The parameters to the RPC operation. It does not take an argument. The
substatements to "output" define nodes under the RPC's output node. substatements to "output" define nodes under the operation's output
node.
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 use this value in the same cases as described in Section 7.6.1. MUST use this value in the same cases as described in Section 7.6.1.
In these cases, the client MUST operationally behave as if the leaf In these cases, the client MUST operationally behave as if the leaf
was present in the NETCONF RPC reply with the default value as its was present in the NETCONF RPC reply with the default value as its
value. value.
skipping to change at page 94, line 38 skipping to change at page 93, line 38
<rock-the-house xmlns="http://example.net/rock"> <rock-the-house xmlns="http://example.net/rock">
<zip-code>27606-0100</zip-code> <zip-code>27606-0100</zip-code>
</rock-the-house> </rock-the-house>
</rpc> </rpc>
<rpc-reply message-id="101" <rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/> <ok/>
</rpc-reply> </rpc-reply>
7.14. The notification Statement 7.14. The action Statement
The "action" statement is used to define an operation connected to a
specific container or list data node. It takes one argument, which
is an identifier, followed by a block of substatements that holds
detailed action information. The argument is the name of the action.
The "action" statement defines an action node in the schema tree.
Under the action node, a schema node with the name "input", and a
schema node with the name "output" are also defined. The nodes
"input" and "output" are defined in the module's namespace.
An action MUST NOT be defined within an rpc, another action or a
notification, i.e., an action node MUST NOT have an rpc, action, or a
notification node as one of its ancestors in the schema tree. For
example, this means that it is an error if a grouping that contains
an action is used in a notification definition.
The difference between an action and an rpc is that an action is tied
to a node in the data tree, whereas an rpc is not. When an action is
invoked, the node in the data tree is specified along with the name
of the action and the input parameters.
7.14.1. The action's Substatements
+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| description | 7.20.3 | 0..1 |
| grouping | 7.11 | 0..n |
| if-feature | 7.19.2 | 0..n |
| input | 7.13.2 | 0..1 |
| output | 7.13.3 | 0..1 |
| reference | 7.20.4 | 0..1 |
| status | 7.20.2 | 0..1 |
| typedef | 7.3 | 0..n |
+--------------+---------+-------------+
7.14.2. XML Mapping Rules
When an action is invoked, an element with the local name "action" in
the namespace "urn:ietf:params:xml:ns:yang:1" (see Section 5.3.1) is
encoded as a child XML element to the <rpc> element defined in
[RFC6241], as designated by the substitution group "rpcOperation" in
[RFC6241].
The "action" element contains an hierarchy of nodes that identifies
the node in the data tree. It MUST contain all containers and list
nodes from the top level down to the list or container containing the
action. For lists, all key leafs MUST also be included. The last
container or list contains an XML element that carries the name of
the defined action. Within this element the input parameters are
encoded as child XML elements, in the same order as they are defined
within the "input" statement.
Only one action can be invoked in one <rpc>. If more than one
actions are present in the <rpc>, the server MUST reply with an
"bad-element" error-tag in the <rpc-error>.
If the action operation invocation succeeded, and no output
parameters are returned, the <rpc-reply> contains a single <ok/>
element defined in [RFC6241]. If output parameters are returned,
they are encoded as child elements to the <rpc-reply> element defined
in [RFC6241], in the same order as they are defined within the
"output" statement.
7.14.3. Usage Example
The following example defines an action to reset one server at a
server farm:
module server-farm {
yang-version 1.1;
namespace "http://example.net/server-farm";
prefix "sfarm";
import ietf-yang-types {
prefix "yang";
}
list server {
key name;
leaf name {
type string;
}
action reset {
input {
leaf reset-at {
type yang:date-and-time;
mandatory true;
}
}
output {
leaf reset-finished-at {
type yang:date-and-time;
mandatory true;
}
}
}
}
}
A corresponding XML instance example of the complete rpc and rpc-
reply:
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<action xmlns="urn:ietf:params:xml:ns:yang:1">
<server xmlns="http://example.net/server-farm">
<name>apache-1</name>
<reset>
<reset-at>2014-07-29T13:42:00Z</reset-at>
</reset>
</server>
</action>
</rpc>
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<reset-finished-at xmlns="http://example.net/server-farm">
2014-07-29T13:42:12Z
</reset-at>
</rpc-reply>
7.15. The notification Statement
The "notification" statement is used to define a NETCONF The "notification" statement is used to define a NETCONF
notification. It takes one argument, which is an identifier, notification. It takes one argument, which is an identifier,
followed by a block of substatements that holds detailed notification followed by a block of substatements that holds detailed notification
information. The "notification" statement defines a notification information. The "notification" statement defines a notification
node in the schema tree. node in the schema tree.
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.
skipping to change at page 95, line 16 skipping to change at page 97, line 5
If a leaf-list in the notification tree has one or more default If a leaf-list in the notification tree has one or more default
values, the NETCONF client MUST use these values in the same cases as values, the NETCONF client MUST use these values in the same cases as
described in Section 7.7.2. In these cases, the client MUST described in Section 7.7.2. In these cases, the client MUST
operationally behave as if the leaf-list was present in the NETCONF operationally behave as if the leaf-list was present in the NETCONF
notification with the default values as its values. notification with the default values as its values.
If a "config" statement is present for any node in the notification If a "config" statement is present for any node in the notification
tree, the "config" statement is ignored. tree, the "config" statement is ignored.
7.14.1. The notification's Substatements 7.15.1. The notification's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| grouping | 7.11 | 0..n | | grouping | 7.11 | 0..n |
| if-feature | 7.18.2 | 0..n | | if-feature | 7.19.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.3 | 0..n | | must | 7.5.3 | 0..n |
| reference | 7.19.4 | 0..1 | | reference | 7.20.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.20.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 Mapping Rules 7.15.2. XML Mapping 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 NETCONF Event Notifications <notification> element defined in NETCONF Event Notifications
[RFC5277]. The element's local name is the notification's [RFC5277]. The element's local name is the notification's
identifier, and its namespace is the module's XML namespace (see identifier, and its namespace is the module's XML namespace (see
Section 7.1.3). Section 7.1.3).
7.14.3. Usage Example 7.15.3. Usage Example
The following example defines a notification: The following example defines a notification:
module event { module event {
yang-version 1.1; yang-version 1.1;
namespace "http://example.com/event"; namespace "http://example.com/event";
prefix "ev"; prefix "ev";
notification event { notification event {
leaf event-class { leaf event-class {
skipping to change at page 96, line 35 skipping to change at page 98, line 19
<eventTime>2008-07-08T00:01:00Z</eventTime> <eventTime>2008-07-08T00:01:00Z</eventTime>
<event xmlns="http://example.com/event"> <event xmlns="http://example.com/event">
<event-class>fault</event-class> <event-class>fault</event-class>
<reporting-entity> <reporting-entity>
<card>Ethernet0</card> <card>Ethernet0</card>
</reporting-entity> </reporting-entity>
<severity>major</severity> <severity>major</severity>
</event> </event>
</notification> </notification>
7.15. The augment Statement 7.16. 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 an external module, or the current module and schema tree defined in an external module, or the current module and
its submodules, and to add to the nodes from a grouping in a "uses" its submodules, and to add to the nodes from a grouping in a "uses"
statement. The argument is a string that identifies a node in the statement. The argument is a string that identifies a node in the
schema tree. This node is called the augment's target node. The schema tree. This node is called the augment's target node. The
target node MUST be either a container, list, choice, case, input, target node MUST be either a container, list, choice, case, input,
output, or notification node. It is augmented with the nodes defined output, or notification node. It is augmented with the nodes defined
in the substatements that follow the "augment" statement. in the substatements that follow the "augment" statement.
skipping to change at page 97, line 20 skipping to change at page 99, line 5
If the target node is a choice node, the "case" statement, or a case If the target node is a choice node, the "case" statement, or a case
shorthand statement (see Section 7.9.2) can be used within the shorthand statement (see Section 7.9.2) can be used within the
"augment" statement. "augment" statement.
If the target node is in another module, then nodes added by the If the target node is in another module, then nodes added by the
augmentation MUST NOT be mandatory nodes (see Section 3.1). augmentation MUST NOT be mandatory nodes (see Section 3.1).
The "augment" statement MUST NOT add multiple nodes with the same The "augment" statement MUST NOT add multiple nodes with the same
name from the same module to the target node. name from the same module to the target node.
7.15.1. The augment's Substatements 7.16.1. The augment's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| action | 7.14 | 0..n |
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 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.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| if-feature | 7.18.2 | 0..n | | if-feature | 7.19.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.19.4 | 0..1 | | reference | 7.20.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.20.2 | 0..1 |
| uses | 7.12 | 0..n | | uses | 7.12 | 0..n |
| when | 7.19.5 | 0..1 | | when | 7.20.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.15.2. XML Mapping Rules 7.16.2. XML Mapping 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 augmenting child nodes are encoded as When a node is augmented, the augmenting child nodes are encoded as
subelements to the augmented node, in any order. subelements to the augmented node, in any order.
7.15.3. Usage Example 7.16.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 100, line 5 skipping to change at page 101, line 33
</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 identity Statement 7.17. The identity Statement
The "identity" statement is used to define a new globally unique, The "identity" statement is used to define a new globally unique,
abstract, and untyped identity. Its only purpose is to denote its abstract, and untyped identity. Its only purpose is to denote its
name, semantics, and existence. An identity can either be defined name, semantics, and existence. An identity can either be defined
from scratch or derived from one or more base identities. The from scratch or derived from one or more base identities. The
identity's argument is an identifier that is the name of the identity's argument is an identifier that is the name of the
identity. It is followed by a block of substatements that holds identity. It is followed by a block of substatements that holds
detailed identity information. detailed identity information.
The built-in datatype "identityref" (see Section 9.10) can be used to The built-in datatype "identityref" (see Section 9.10) can be used to
reference identities within a data model. reference identities within a data model.
7.16.1. The identity's Substatements 7.17.1. The identity's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| base | 7.16.2 | 0..n | | base | 7.17.2 | 0..n |
| description | 7.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| if-feature | 7.18.2 | 0..n | | if-feature | 7.19.2 | 0..n |
| reference | 7.19.4 | 0..1 | | reference | 7.20.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.20.2 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.16.2. The base Statement 7.17.2. The base Statement
The "base" statement, which is optional, takes as an argument a The "base" statement, which is optional, takes as an argument a
string that is the name of an existing identity, from which the new string that is the name of an existing identity, from which the new
identity is derived. If no "base" statement is present, the identity identity is derived. If no "base" statement is present, the identity
is defined from scratch. If multiple "base" statements are present, is defined from scratch. If multiple "base" statements are present,
the identity is derived from all of them. the identity is derived from all of them.
If a prefix is present on the base name, it refers to an identity If a prefix is present on the base name, it refers to an identity
defined in the module that was imported with that prefix, or the defined in the module that was imported with that prefix, or the
local module if the prefix matches the local module's prefix. local module if the prefix matches the local module's prefix.
Otherwise, an identity with the matching name MUST be defined in the Otherwise, an identity with the matching name MUST be defined in the
current module or an included submodule. current module or an included submodule.
Since submodules cannot include the parent module, any identities in
the module that 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.
An identity MUST NOT reference itself, neither directly nor An identity MUST NOT reference itself, neither directly nor
indirectly through a chain of other identities. indirectly through a chain of other identities.
The derivation of identities has the following properties: The derivation of identities has the following properties:
o It is irreflexive, which means that an identity is not derived o It is irreflexive, which means that an identity is not derived
from itself. from itself.
o It is transitive, which means that if identity B is derived from A o It is transitive, which means that if identity B is derived from A
and C is derived from B, then C is also derived from A. and C is derived from B, then C is also derived from A.
7.16.3. Usage Example 7.17.3. Usage Example
module crypto-base { module crypto-base {
yang-version 1.1; yang-version 1.1;
namespace "http://example.com/crypto-base"; namespace "http://example.com/crypto-base";
prefix "crypto"; prefix "crypto";
identity crypto-alg { identity crypto-alg {
description description
"Base identity from which all crypto algorithms "Base identity from which all crypto algorithms
are derived."; are derived.";
} }
skipping to change at page 101, line 45 skipping to change at page 103, line 36
base "crypto:crypto-alg"; base "crypto:crypto-alg";
description "DES crypto algorithm"; description "DES crypto algorithm";
} }
identity des3 { identity des3 {
base "crypto:crypto-alg"; base "crypto:crypto-alg";
description "Triple DES crypto algorithm"; description "Triple DES crypto algorithm";
} }
} }
7.17. The extension Statement 7.18. 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 102, line 20 skipping to change at page 104, line 12
"extension" statement, and an optional block of substatements. The "extension" statement, and an optional block of substatements. The
statement's name is created by combining the prefix of the module in statement's name is created by combining the prefix of the module in
which the extension was defined, a colon (":"), and the extension's which the extension was defined, a colon (":"), and the extension's
keyword, with no interleaving whitespace. The substatements of an keyword, with no interleaving whitespace. The substatements of an
extension are defined by the "extension" statement, using some extension are defined by the "extension" statement, using some
mechanism outside the scope of this specification. Syntactically, mechanism outside the scope of this specification. Syntactically,
the substatements MUST be YANG statements, or also extensions defined the substatements MUST be YANG statements, or also extensions defined
using "extension" statements. YANG statements in extensions MUST using "extension" statements. YANG statements in extensions MUST
follow the syntactical rules in Section 13. follow the syntactical rules in Section 13.
7.17.1. The extension's Substatements 7.18.1. The extension's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| argument | 7.17.2 | 0..1 | | argument | 7.18.2 | 0..1 |
| description | 7.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| reference | 7.19.4 | 0..1 | | reference | 7.20.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.20.2 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.17.2. The argument Statement 7.18.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 that is the name of the argument to the keyword. If no string that 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 an XML attribute or element name, depending on the argument's
"yin-element" statement. "yin-element" statement.
7.17.2.1. The argument's Substatements 7.18.2.1. The argument's Substatements
+--------------+----------+-------------+ +--------------+----------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+----------+-------------+ +--------------+----------+-------------+
| yin-element | 7.17.2.2 | 0..1 | | yin-element | 7.18.2.2 | 0..1 |
+--------------+----------+-------------+ +--------------+----------+-------------+
7.17.2.2. The yin-element Statement 7.18.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 is mapped to an XML element in YIN or to an XML attribute argument is mapped to an XML element in YIN or to an XML attribute
(see Section 12). (see Section 12).
If no "yin-element" statement is present, it defaults to "false". If no "yin-element" statement is present, it defaults to "false".
7.17.3. Usage Example 7.18.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 103, line 45 skipping to change at page 105, line 36
prefix "myext"; prefix "myext";
} }
... ...
container interfaces { container interfaces {
... ...
myext:c-define "MY_INTERFACES"; myext:c-define "MY_INTERFACES";
} }
} }
7.18. Conformance-Related Statements 7.19. Conformance-Related Statements
This section defines statements related to conformance, as described This section defines statements related to conformance, as described
in Section 5.6. in Section 5.6.
7.18.1. The feature Statement 7.19.1. The feature Statement
The "feature" statement is used to define a mechanism by which The "feature" statement is used to define a mechanism by which
portions of the schema are marked as conditional. A feature name is portions of the schema are marked as conditional. A feature name is
defined that can later be referenced using the "if-feature" statement defined that can later be referenced using the "if-feature" statement
(see Section 7.18.2). Schema nodes tagged with an "if-feature" (see Section 7.19.2). Schema nodes tagged with an "if-feature"
statement are ignored by the device unless the device supports the statement are ignored by the device unless the device supports the
given feature expression. This allows portions of the YANG module to given feature expression. This allows portions of the YANG module to
be conditional based on conditions on the device. The model can be conditional based on conditions on the device. The model can
represent the abilities of the device within the model, giving a represent the abilities of the device within the model, giving a
richer model that allows for differing device abilities and roles. richer model that allows for differing device abilities and roles.
The argument to the "feature" statement is the name of the new The argument to the "feature" statement is the name of the new
feature, and follows the rules for identifiers in Section 6.2. This 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 name is used by the "if-feature" statement to tie the schema nodes to
the feature. the feature.
skipping to change at page 105, line 17 skipping to change at page 107, line 5
device does not support that feature. device does not support that feature.
A feature MUST NOT reference itself, neither directly nor indirectly A feature MUST NOT reference itself, neither directly nor indirectly
through a chain of other features. through a chain of other features.
In order for a device to implement a feature that is dependent on any In order for a device to implement a feature that is dependent on any
other features (i.e., the feature has one or more "if-feature" other features (i.e., the feature has one or more "if-feature"
substatements), the device MUST also implement all the dependant substatements), the device MUST also implement all the dependant
features. features.
7.18.1.1. The feature's Substatements 7.19.1.1. The feature's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| description | 7.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| if-feature | 7.18.2 | 0..n | | if-feature | 7.19.2 | 0..n |
| status | 7.19.2 | 0..1 | | status | 7.20.2 | 0..1 |
| reference | 7.19.4 | 0..1 | | reference | 7.20.4 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.18.2. The if-feature Statement 7.19.2. The if-feature Statement
The "if-feature" statement makes its parent statement conditional. The "if-feature" statement makes its parent statement conditional.
The argument is a boolean expression over feature names. In this The argument is a boolean expression over feature names. In this
expression, a feature name evaluates to "true" if and only if the expression, a feature name evaluates to "true" if and only if the
feature is implemented by the server. The parent statement is feature is implemented by the server. The parent statement is
implemented by servers where the boolean expression evaluates to implemented by servers where the boolean expression evaluates to
"true". "true".
The if-feature boolean expression syntax is formally defined by the The if-feature boolean expression syntax is formally defined by the
rule "if-feature-expr" in Section 13. When this boolean expression rule "if-feature-expr" in Section 13. When this boolean expression
is evaluated, the operator order of precedence is (highest precedence is evaluated, the operator order of precedence is (highest precedence
first): "not", "and", "or". first): "not", "and", "or".
If a prefix is present on a feature name in the boolean expression, If a prefix is present on a feature name in the boolean expression,
the prefixed name refers to a feature defined in the module that was the prefixed name refers to a feature defined in the module that was
imported with that prefix, or the local module if the prefix matches imported with that prefix, or the local module if the prefix matches
the local module's prefix. Otherwise, a feature with the matching the local module's prefix. Otherwise, a feature with the matching
name MUST be defined in the current module or an included submodule. name MUST be defined in the current module or an included submodule.
Since submodules cannot include the parent module, any features in
the module that 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.
A leaf that is a list key MUST NOT have any "if-feature" statements, A leaf that is a list key MUST NOT have any "if-feature" statements,
unless the conditions specified in the "if-feature" statements are unless the conditions specified in the "if-feature" statements are
the same as the "if-feature" conditions in effect on the leaf's the same as the "if-feature" conditions in effect on the leaf's
parent node. parent node.
7.18.2.1. Usage Example 7.19.2.1. Usage Example
In this example, the container "target" is implemented if any of the In this example, the container "target" is implemented if any of the
features "outbound-tls" or "outbound-ssh" is implemented by the features "outbound-tls" or "outbound-ssh" is implemented by the
server. server.
container target { container target {
if-feature "outbound-tls or outbound-ssh"; if-feature "outbound-tls or outbound-ssh";
... ...
} }
7.18.3. The deviation Statement 7.19.3. The deviation Statement
The "deviation" statement defines a hierarchy of a module that the The "deviation" statement defines a hierarchy of a module that the
device does not implement faithfully. The argument is a string that device does not implement faithfully. The argument is a string that
identifies the node in the schema tree where a deviation from the identifies the node in the schema tree where a deviation from the
module occurs. This node is called the deviation's target node. The module occurs. This node is called the deviation's target node. The
contents of the "deviation" statement give details about the contents of the "deviation" statement give details about the
deviation. deviation.
The argument string is an absolute schema node identifier (see The argument string is an absolute schema node identifier (see
Section 6.5). Section 6.5).
skipping to change at page 107, line 9 skipping to change at page 108, line 39
or software ability to support parts of a standard module. When this or software ability to support parts of a standard module. When this
occurs, the device makes a choice either to treat attempts to occurs, the device makes a choice either to treat attempts to
configure unsupported parts of the module as an error that is configure unsupported parts of the module as an error that is
reported back to the unsuspecting application or ignore those reported back to the unsuspecting application or ignore those
incoming requests. Neither choice is acceptable. incoming requests. Neither choice is acceptable.
Instead, YANG allows devices to document portions of a base module Instead, YANG allows devices to document portions of a base module
that are not supported or supported but with different syntax, by that are not supported or supported but with different syntax, by
using the "deviation" statement. using the "deviation" statement.
7.18.3.1. The deviation's Substatements 7.19.3.1. The deviation's Substatements
+--------------+----------+-------------+ +--------------+----------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+----------+-------------+ +--------------+----------+-------------+
| description | 7.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| deviate | 7.18.3.2 | 1..n | | deviate | 7.19.3.2 | 1..n |
| reference | 7.19.4 | 0..1 | | reference | 7.20.4 | 0..1 |
+--------------+----------+-------------+ +--------------+----------+-------------+
7.18.3.2. The deviate Statement 7.19.3.2. The deviate Statement
The "deviate" statement defines how the device's implementation of The "deviate" statement defines how the device's implementation of
the target node deviates from its original definition. The argument the target node deviates from its original definition. The argument
is one of the strings "not-supported", "add", "replace", or "delete". is one of the strings "not-supported", "add", "replace", or "delete".
The argument "not-supported" indicates that the target node is not The argument "not-supported" indicates that the target node is not
implemented by this device. implemented by this device.
The argument "add" adds properties to the target node. The The argument "add" adds properties to the target node. The
properties to add are identified by substatements to the "deviate" properties to add are identified by substatements to the "deviate"
skipping to change at page 108, line 8 skipping to change at page 109, line 33
The argument "delete" deletes properties from the target node. The The argument "delete" deletes properties from the target node. The
properties to delete are identified by substatements to the "delete" properties to delete are identified by substatements to the "delete"
statement. The substatement's keyword MUST match a corresponding statement. The substatement's keyword MUST match a corresponding
keyword in the target node, and the argument's string MUST be equal keyword in the target node, and the argument's string MUST be equal
to the corresponding keyword's argument string in the target node. to the corresponding keyword's argument string in the target node.
+--------------+-------------+-------------+ +--------------+-------------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+-------------+-------------+ +--------------+-------------+-------------+
| config | 7.19.1 | 0..1 | | config | 7.20.1 | 0..1 |
| default | 7.6.4 7.7.4 | 0..n | | default | 7.6.4 7.7.4 | 0..n |
| mandatory | 7.6.5 | 0..1 | | mandatory | 7.6.5 | 0..1 |
| max-elements | 7.7.6 | 0..1 | | max-elements | 7.7.6 | 0..1 |
| min-elements | 7.7.5 | 0..1 | | min-elements | 7.7.5 | 0..1 |
| must | 7.5.3 | 0..n | | must | 7.5.3 | 0..n |
| type | 7.4 | 0..1 | | type | 7.4 | 0..1 |
| unique | 7.8.3 | 0..n | | unique | 7.8.3 | 0..n |
| units | 7.3.3 | 0..1 | | units | 7.3.3 | 0..1 |
+--------------+-------------+-------------+ +--------------+-------------+-------------+
The deviate's Substatements The deviate's Substatements
7.18.3.3. Usage Example 7.19.3.3. Usage Example
In this example, the device is informing client applications that it In this example, the device is informing client applications that it
does not support the "daytime" service in the style of RFC 867. does not support the "daytime" service in the style of RFC 867.
deviation /base:system/base:daytime { deviation /base:system/base:daytime {
deviate not-supported; deviate not-supported;
} }
The following example sets a device-specific default value to a leaf The following example sets a device-specific default value to a leaf
that does not have a default value defined: that does not have a default value defined:
skipping to change at page 109, line 13 skipping to change at page 110, line 41
} }
a device might remove this must constraint by doing: a device might remove this must constraint by doing:
deviation "/base:system" { deviation "/base:system" {
deviate delete { deviate delete {
must "daytime or time"; must "daytime or time";
} }
} }
7.19. Common Statements 7.20. Common Statements
This section defines substatements common to several other This section defines substatements common to several other
statements. statements.
7.19.1. The config Statement 7.20.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. Data nodes representing configuration will be part of configuration. Data nodes representing configuration will be part of
the reply to a <get-config> request, and can be sent in a the reply to a <get-config> request, and can be sent in a
<copy-config> or <edit-config> request. <copy-config> or <edit-config> request.
If "config" is "false", the definition represents state data. Data If "config" is "false", the definition represents state data. Data
nodes representing state data will be part of the reply to a <get>, nodes representing state data will be part of the reply to a <get>,
but not to a <get-config> request, and cannot be sent in a but not to a <get-config> request, and cannot be sent in a
skipping to change at page 109, line 41 skipping to change at page 111, line 20
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
schema node's "config" value. If the parent node is a "case" node, schema node's "config" value. If the parent node is a "case" node,
the value is the same as the "case" node's parent "choice" node. the value is the same as the "case" node's parent "choice" node.
If the top node does not specify a "config" statement, the default is If the top node does not specify a "config" statement, the default is
"true". "true".
If a node has "config" set to "false", no node underneath it can have If a node has "config" set to "false", no node underneath it can have
"config" set to "true". "config" set to "true".
7.19.2. The status Statement 7.20.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 110, line 28 skipping to change at page 112, line 5
typedef my-type { typedef my-type {
status deprecated; status deprecated;
type int32; type int32;
} }
leaf my-leaf { leaf my-leaf {
status current; status current;
type my-type; // illegal, since my-type is deprecated type my-type; // illegal, since my-type is deprecated
} }
7.19.3. The description Statement 7.20.3. The description Statement
The "description" statement takes as an argument a string that The "description" statement takes as an argument a string that
contains a human-readable textual description of this definition. contains a human-readable textual description of this definition.
The text is provided in a language (or languages) chosen by the The text is provided in a language (or languages) chosen by the
module developer; for the sake of interoperability, it is RECOMMENDED module developer; for the sake of interoperability, it is RECOMMENDED
to choose a language that is widely understood among the community of to choose a language that is widely understood among the community of
network administrators who will use the module. network administrators who will use the module.
7.19.4. The reference Statement 7.20.4. The reference Statement
The "reference" statement takes as an argument a string that is used The "reference" statement takes as an argument a string that is 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 that defines related management information, or a another module that defines related management information, or a
document that provides additional information relevant to this document that provides additional information relevant to this
definition. definition.
For example, a typedef for a "uri" data type could look like: For example, a typedef for a "uri" data type could look like:
typedef uri { typedef uri {
type string; type string;
reference reference
"RFC 3986: Uniform Resource Identifier (URI): Generic Syntax"; "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax";
... ...
} }
7.19.5. The when Statement 7.20.5. The when Statement
The "when" statement makes its parent data definition statement The "when" statement makes its parent data definition statement
conditional. The node defined by the parent data definition conditional. The node defined by the parent data definition
statement is only valid when the condition specified by the "when" statement is only valid when the condition specified by the "when"
statement is satisfied. The statement's argument is an XPath statement is satisfied. The statement's argument is an XPath
expression (see Section 6.4), which is used to formally specify this expression (see Section 6.4), which is used to formally specify this
condition. If the XPath expression conceptually evaluates to "true" condition. If the XPath expression conceptually evaluates to "true"
for a particular instance, then the node defined by the parent data for a particular instance, then the node defined by the parent data
definition statement is valid; otherwise, it is not. definition statement is valid; otherwise, it is not.
skipping to change at page 111, line 43 skipping to change at page 113, line 20
node to the "uses", "choice", or "case" node that is also a data node to the "uses", "choice", or "case" node that is also a data
node. node.
o If the "when" statement is a child of any other data definition o If the "when" statement is a child of any other data definition
statement, the context node is the node in the accessible tree for statement, the context node is the node in the accessible tree for
which the "when" statement is defined. which the "when" statement is defined.
The result of the XPath expression is converted to a boolean value The result of the XPath expression is converted to a boolean value
using the standard XPath rules. using the standard XPath rules.
If the XPath expression references any node that also has associated
"when" statements, these "when" expressions MUST be evaluated first.
There MUST NOT be any circular dependencies in these "when"
expressions.
Note that the XPath expression is conceptually evaluated. This means Note that the XPath expression is conceptually evaluated. This means
that an implementation does not have to use an XPath evaluator on the that an implementation does not have to use an XPath evaluator on the
device. The "when" statement can very well be implemented with device. The "when" statement can very well be implemented with
specially written code. specially written code.
8. Constraints 8. Constraints
8.1. Constraints on Data 8.1. Constraints on Data
Several YANG statements define constraints on valid data. These Several YANG statements define constraints on valid data. These
constraints are enforced in different ways, depending on what type of constraints are enforced in different ways, depending on what type of
data the statement defines. data the statement defines.
o If the constraint is defined on configuration data, it MUST be o If the constraint is defined on configuration data, it MUST be
true in a valid configuration data tree. true in a valid configuration data tree.
o If the constraint is defined on state data, it MUST be true in a o If the constraint is defined on state data, it MUST be true in a
skipping to change at page 117, line 34 skipping to change at page 119, line 13
for the type being restricted, respectively. for the type being restricted, respectively.
The range expression syntax is formally defined by the rule The range expression syntax is formally defined by the rule
"range-arg" in Section 13. "range-arg" in Section 13.
9.2.4.1. The range's Substatements 9.2.4.1. The range's Substatements
+---------------+---------+-------------+ +---------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+---------------+---------+-------------+ +---------------+---------+-------------+
| description | 7.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| error-app-tag | 7.5.4.2 | 0..1 | | error-app-tag | 7.5.4.2 | 0..1 |
| error-message | 7.5.4.1 | 0..1 | | error-message | 7.5.4.1 | 0..1 |
| reference | 7.19.4 | 0..1 | | reference | 7.20.4 | 0..1 |
+---------------+---------+-------------+ +---------------+---------+-------------+
9.2.5. 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";
} }
} }
typedef my-type1 { typedef my-type1 {
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
skipping to change at page 121, line 13 skipping to change at page 122, line 48
18446744073709551615. 18446744073709551615.
The length expression syntax is formally defined by the rule The length expression syntax is formally defined by the rule
"length-arg" in Section 13. "length-arg" in Section 13.
9.4.4.1. The length's Substatements 9.4.4.1. The length's Substatements
+---------------+---------+-------------+ +---------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+---------------+---------+-------------+ +---------------+---------+-------------+
| description | 7.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| error-app-tag | 7.5.4.2 | 0..1 | | error-app-tag | 7.5.4.2 | 0..1 |
| error-message | 7.5.4.1 | 0..1 | | error-message | 7.5.4.1 | 0..1 |
| reference | 7.19.4 | 0..1 | | reference | 7.20.4 | 0..1 |
+---------------+---------+-------------+ +---------------+---------+-------------+
9.4.5. The pattern Statement 9.4.5. 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 match the "string", or types derived from "string", to values that match the
pattern. pattern.
skipping to change at page 121, line 39 skipping to change at page 123, line 25
If a pattern restriction is applied to an already pattern-restricted If a pattern restriction is applied to an already pattern-restricted
type, values must match all patterns in the base type, in addition to type, values must match all patterns in the base type, in addition to
the new patterns. the new patterns.
9.4.5.1. The pattern's Substatements 9.4.5.1. The pattern's Substatements
+---------------+---------+-------------+ +---------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+---------------+---------+-------------+ +---------------+---------+-------------+
| description | 7.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| error-app-tag | 7.5.4.2 | 0..1 | | error-app-tag | 7.5.4.2 | 0..1 |
| error-message | 7.5.4.1 | 0..1 | | error-message | 7.5.4.1 | 0..1 |
| modifier | 9.4.6 | 0..1 | | modifier | 9.4.6 | 0..1 |
| reference | 7.19.4 | 0..1 | | reference | 7.20.4 | 0..1 |
+---------------+---------+-------------+ +---------------+---------+-------------+
9.4.6. The modifier Statement 9.4.6. The modifier Statement
9.4.7. Usage Example 9.4.7. Usage Example
With the following typedef: With the following typedef:
typedef my-base-str-type { typedef my-base-str-type {
type string { type string {
skipping to change at page 124, line 30 skipping to change at page 126, line 15
When an existing enumeration type is restricted, the set of assigned When an existing enumeration type is restricted, the set of assigned
names in the new type MUST be a subset of the base type's set of names in the new type MUST be a subset of the base type's set of
assigned names. The value of such an assigned name MUST not be assigned names. The value of such an assigned name MUST not be
changed. changed.
9.6.4.1. The enum's Substatements 9.6.4.1. The enum's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| description | 7.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| if-feature | 7.18.2 | 0..n | | if-feature | 7.19.2 | 0..n |
| reference | 7.19.4 | 0..1 | | reference | 7.20.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.20.2 | 0..1 |
| value | 9.6.4.2 | 0..1 | | value | 9.6.4.2 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
9.6.4.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. The value is unused by YANG and unique within the enumeration type.
the XML encoding, but is carried as a convenience to implementors.
If a value is not specified, then one will be automatically assigned. If a value is not specified, then one will be automatically assigned.
If the "enum" substatement is the first one defined, the assigned If the "enum" substatement is the first one defined, the assigned
value is zero (0); otherwise, the assigned value is one greater than value is zero (0); otherwise, the assigned value is one greater than
the current highest enum value (i.e., the highest enum value, the current highest enum value (i.e., the highest enum value,
implicit or explicit, prior to the current "enum" substatement in the implicit or explicit, prior to the current "enum" substatement in the
parent "type" statement). parent "type" statement).
If the current highest value is equal to 2147483647, then an enum If the current highest value is equal to 2147483647, then an enum
value MUST be specified for "enum" substatements following the one value MUST be specified for "enum" substatements following the one
skipping to change at page 127, line 10 skipping to change at page 129, line 4
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 that is the assigned name of the bit. It is argument a string that is the assigned name of the bit. It is
followed by a block of substatements that holds detailed bit followed by a block of substatements that holds detailed bit
information. The assigned name follows the same syntax rules as an information. The assigned name follows the same syntax rules as an
identifier (see Section 6.2). identifier (see Section 6.2).
All assigned names in a bits type MUST be unique. All assigned names in a bits type MUST be unique.
9.7.4.1. The bit's Substatements 9.7.4.1. The bit's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| description | 7.19.3 | 0..1 | | description | 7.20.3 | 0..1 |
| if-feature | 7.18.2 | 0..n | | if-feature | 7.19.2 | 0..n |
| reference | 7.19.4 | 0..1 | | reference | 7.20.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.20.2 | 0..1 |
| position | 9.7.4.2 | 0..1 | | position | 9.7.4.2 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
9.7.4.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 that specifies the bit's position within a non-negative integer value that specifies the bit's position within a
hypothetical bit field. The position value MUST be in the range 0 to hypothetical bit field. The position value MUST be in the range 0 to
4294967295, and it MUST be unique within the bits type. The value is 4294967295, and it MUST be unique within the bits type. The value is
unused by YANG and the NETCONF messages, but is carried as a unused by YANG and the NETCONF messages, but is carried as a
skipping to change at page 129, line 16 skipping to change at page 130, line 49
the "require-instance" property (Section 9.9.3) is "true", the leaf the "require-instance" property (Section 9.9.3) is "true", the leaf
it refers to MUST also represent configuration. Such a leaf puts a it refers to MUST also represent configuration. Such a leaf puts a
constraint on valid data. All such nodes MUST reference existing constraint on valid data. All such nodes MUST reference existing
leaf instances or leafs with default values in use (see Section 7.6.1 leaf instances or leafs with default values in use (see Section 7.6.1
and Section 7.7.2) for the data to be valid. This constraint is and Section 7.7.2) for the data to be valid. This constraint is
enforced according to the rules in Section 8. enforced according to the rules in Section 8.
There MUST NOT be any circular chains of leafrefs. There MUST NOT be any circular chains of leafrefs.
If the leaf that the leafref refers to is conditional based on one or If the leaf that the leafref refers to is conditional based on one or
more features (see Section 7.18.2), then the leaf with the leafref more features (see Section 7.19.2), then the leaf with the leafref
type MUST also be conditional based on at least the same set of type MUST also be conditional based on at least the same set of
features. features.
9.9.1. Restrictions 9.9.1. Restrictions
A leafref can be restricted with the "require-instance" statement A leafref can be restricted with the "require-instance" statement
(Section 9.9.3). (Section 9.9.3).
9.9.2. The path Statement 9.9.2. The path Statement
skipping to change at page 134, line 34 skipping to change at page 136, line 17
<eventTime>2008-04-01T00:01:00Z</eventTime> <eventTime>2008-04-01T00:01:00Z</eventTime>
<link-failure xmlns="http://acme.example.com/system"> <link-failure xmlns="http://acme.example.com/system">
<if-name>eth0</if-name> <if-name>eth0</if-name>
<admin-status>up</admin-status> <admin-status>up</admin-status>
</link-failure> </link-failure>
</notification> </notification>
9.10. The identityref Built-In Type 9.10. The identityref Built-In Type
The identityref type is used to reference an existing identity (see The identityref type is used to reference an existing identity (see
Section 7.16). Section 7.17).
9.10.1. Restrictions 9.10.1. Restrictions
An identityref cannot be restricted. An identityref cannot be restricted.
9.10.2. The identityref's base Statement 9.10.2. The identityref's base Statement
The "base" statement, which is a substatement to the "type" The "base" statement, which is a substatement to the "type"
statement, MUST be present at least once if the type is statement, MUST be present at least once if the type is
"identityref". The argument is the name of an identity, as defined "identityref". The argument is the name of an identity, as defined
skipping to change at page 135, line 37 skipping to change at page 137, line 19
corresponding "import" statement. Otherwise, the prefix in the corresponding "import" statement. Otherwise, the prefix in the
string value is the prefix for the current module. string value is the prefix for the current module.
9.10.4. Canonical Form 9.10.4. Canonical Form
Since the lexical form depends on the XML context in which the value Since the lexical form depends on the XML context in which the value
occurs, this type does not have a canonical form. occurs, this type does not have a canonical form.
9.10.5. Usage Example 9.10.5. Usage Example
With the identity definitions in Section 7.16.3 and the following With the identity definitions in Section 7.17.3 and the following
module: module:
module my-crypto { module my-crypto {
yang-version 1.1; yang-version 1.1;
namespace "http://example.com/my-crypto"; namespace "http://example.com/my-crypto";
prefix mc; prefix mc;
import "crypto-base" { import "crypto-base" {
prefix "crypto"; prefix "crypto";
} }
skipping to change at page 149, line 29 skipping to change at page 150, line 29
via the "extension" statement. via the "extension" statement.
The names of all YIN elements MUST be properly qualified with their The names of all YIN elements MUST be properly qualified with their
namespaces specified above using the standard mechanisms of namespaces specified above using the standard mechanisms of
[XML-NAMES], i.e., "xmlns" and "xmlns:xxx" attributes. [XML-NAMES], i.e., "xmlns" and "xmlns:xxx" attributes.
The argument of a YANG statement is represented in YIN either as an The argument of a YANG statement is represented in YIN either as an
XML attribute or a subelement of the keyword element. Table 1 XML attribute or a subelement of the keyword element. Table 1
defines the mapping for the set of YANG keywords. For extensions, defines the mapping for the set of YANG keywords. For extensions,
the argument mapping is specified within the "extension" statement the argument mapping is specified within the "extension" statement
(see Section 7.17). The following rules hold for arguments: (see Section 7.18). The following rules hold for arguments:
o If the argument is represented as an attribute, this attribute has o If the argument is represented as an attribute, this attribute has
no namespace. no namespace.
o If the argument is represented as an element, it is qualified by o If the argument is represented as an element, it is qualified by
the same namespace as its parent keyword element. the same namespace as its parent keyword element.
o If the argument is represented as an element, it MUST be the first o If the argument is represented as an element, it MUST be the first
child of the keyword element. child of the keyword element.
skipping to change at page 151, line 48 skipping to change at page 152, line 48
} }
leaf mtu { leaf mtu {
type uint32; type uint32;
description "The MTU of the interface."; description "The MTU of the interface.";
myext:c-define "MY_MTU"; myext:c-define "MY_MTU";
} }
} }
} }
where the extension "c-define" is defined in Section 7.17.3, is where the extension "c-define" is defined in Section 7.18.3, is
translated into the following YIN: translated into the following YIN:
<module name="acme-foo" <module name="acme-foo"
xmlns="urn:ietf:params:xml:ns:yang:yin:1" xmlns="urn:ietf:params:xml:ns:yang:yin:1"
xmlns:acfoo="http://acme.example.com/foo" xmlns:acfoo="http://acme.example.com/foo"
xmlns:myext="http://example.com/my-extensions"> xmlns:myext="http://example.com/my-extensions">
<namespace uri="http://acme.example.com/foo"/> <namespace uri="http://acme.example.com/foo"/>
<prefix value="acfoo"/> <prefix value="acfoo"/>
skipping to change at page 153, line 18 skipping to change at page 154, line 18
optsep optsep
"{" stmtsep "{" stmtsep
submodule-header-stmts submodule-header-stmts
linkage-stmts linkage-stmts
meta-stmts meta-stmts
revision-stmts revision-stmts
body-stmts body-stmts
"}" optsep "}" optsep
module-header-stmts = ;; these stmts can appear in any order module-header-stmts = ;; these stmts can appear in any order
yang-version-stmt stmtsep yang-version-stmt
namespace-stmt stmtsep namespace-stmt
prefix-stmt stmtsep prefix-stmt
submodule-header-stmts = submodule-header-stmts =
;; these stmts can appear in any order ;; these stmts can appear in any order
yang-version-stmt stmtsep yang-version-stmt
belongs-to-stmt stmtsep belongs-to-stmt
meta-stmts = ;; these stmts can appear in any order meta-stmts = ;; these stmts can appear in any order
[organization-stmt stmtsep] [organization-stmt]
[contact-stmt stmtsep] [contact-stmt]
[description-stmt stmtsep] [description-stmt]
[reference-stmt stmtsep] [reference-stmt]
linkage-stmts = ;; these stmts can appear in any order linkage-stmts = ;; these stmts can appear in any order
*(import-stmt stmtsep) *import-stmt
*(include-stmt stmtsep) *include-stmt
revision-stmts = *(revision-stmt stmtsep) revision-stmts = *revision-stmt
body-stmts = *((extension-stmt / body-stmts = *(extension-stmt /
feature-stmt / feature-stmt /
identity-stmt / identity-stmt /
typedef-stmt / typedef-stmt /
grouping-stmt / grouping-stmt /
data-def-stmt / data-def-stmt /
augment-stmt / augment-stmt /
rpc-stmt / rpc-stmt /
notification-stmt / notification-stmt /
deviation-stmt) stmtsep) deviation-stmt)
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
yang-version-stmt = yang-version-keyword sep yang-version-arg-str yang-version-stmt = yang-version-keyword sep yang-version-arg-str
optsep stmtend stmtend
yang-version-arg-str = < a string that matches the rule > yang-version-arg-str = < a string that matches the rule >
< yang-version-arg > < yang-version-arg >
yang-version-arg = "1.1" yang-version-arg = "1.1"
import-stmt = import-keyword sep identifier-arg-str optsep import-stmt = import-keyword sep identifier-arg-str optsep
"{" stmtsep "{" stmtsep
prefix-stmt stmtsep prefix-stmt
[revision-date-stmt stmtsep] [revision-date-stmt]
"}" "}" stmtsep
include-stmt = include-keyword sep identifier-arg-str optsep include-stmt = include-keyword sep identifier-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
[revision-date-stmt stmtsep] [revision-date-stmt]
"}") "}") stmtsep
namespace-stmt = namespace-keyword sep uri-str optsep stmtend namespace-stmt = namespace-keyword sep uri-str stmtend
uri-str = < a string that matches the rule > uri-str = < a string that matches the rule >
< URI in RFC 3986 > < URI in RFC 3986 >
prefix-stmt = prefix-keyword sep prefix-arg-str prefix-stmt = prefix-keyword sep prefix-arg-str stmtend
optsep stmtend
belongs-to-stmt = belongs-to-keyword sep identifier-arg-str belongs-to-stmt = belongs-to-keyword sep identifier-arg-str
optsep optsep
"{" stmtsep "{" stmtsep
prefix-stmt stmtsep prefix-stmt
"}" "}" stmtsep
organization-stmt = organization-keyword sep string
optsep stmtend
contact-stmt = contact-keyword sep string optsep stmtend organization-stmt = organization-keyword sep string stmtend
description-stmt = description-keyword sep string optsep contact-stmt = contact-keyword sep string stmtend
stmtend
reference-stmt = reference-keyword sep string optsep stmtend description-stmt = description-keyword sep string stmtend
units-stmt = units-keyword sep string optsep stmtend reference-stmt = reference-keyword sep string stmtend
units-stmt = units-keyword sep string stmtend
revision-stmt = revision-keyword sep revision-date optsep revision-stmt = revision-keyword sep revision-date optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[description-stmt stmtsep] [description-stmt]
[reference-stmt stmtsep] [reference-stmt]
"}") "}") stmtsep
revision-date = date-arg-str revision-date = date-arg-str
revision-date-stmt = revision-date-keyword sep revision-date stmtend revision-date-stmt = revision-date-keyword sep revision-date stmtend
extension-stmt = extension-keyword sep identifier-arg-str optsep extension-stmt = extension-keyword sep identifier-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[argument-stmt stmtsep] [argument-stmt]
[status-stmt stmtsep] [status-stmt]
[description-stmt stmtsep] [description-stmt]
[reference-stmt stmtsep] [reference-stmt]
"}") "}") stmtsep
argument-stmt = argument-keyword sep identifier-arg-str optsep argument-stmt = argument-keyword sep identifier-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
[yin-element-stmt stmtsep] [yin-element-stmt]
"}") "}") stmtsep
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 that matches the rule > yin-element-arg-str = < a string that 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 identity-stmt = identity-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) *if-feature-stmt
*(base-stmt stmtsep) *base-stmt
[status-stmt stmtsep] [status-stmt]
[description-stmt stmtsep] [description-stmt]
[reference-stmt]
[reference-stmt stmtsep] "}") stmtsep
"}")
base-stmt = base-keyword sep identifier-ref-arg-str base-stmt = base-keyword sep identifier-ref-arg-str
optsep stmtend stmtend
feature-stmt = feature-keyword sep identifier-arg-str optsep feature-stmt = feature-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) *if-feature-stmt
[status-stmt stmtsep] [status-stmt]
[description-stmt stmtsep] [description-stmt]
[reference-stmt stmtsep] [reference-stmt]
"}") "}") stmtsep
if-feature-stmt = if-feature-keyword sep if-feature-expr-str if-feature-stmt = if-feature-keyword sep if-feature-expr-str
optsep stmtend stmtend
if-feature-expr-str = < a string that matches the rule > if-feature-expr-str = < a string that matches the rule >
< if-feature-expr > < if-feature-expr >
if-feature-expr = "(" if-feature-expr ")" / if-feature-expr = "(" if-feature-expr ")" /
if-feature-expr sep boolean-operator sep if-feature-expr sep boolean-operator sep
if-feature-expr / if-feature-expr /
not-keyword sep if-feature-expr / not-keyword sep if-feature-expr /
identifier-ref-arg identifier-ref-arg
boolean-operator = and-keyword / or-keyword boolean-operator = and-keyword / or-keyword
typedef-stmt = typedef-keyword sep identifier-arg-str optsep typedef-stmt = typedef-keyword sep identifier-arg-str optsep
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
type-stmt stmtsep type-stmt
[units-stmt stmtsep] [units-stmt]
[default-stmt stmtsep] [default-stmt]
[status-stmt stmtsep] [status-stmt]
[description-stmt stmtsep] [description-stmt]
[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
type-body-stmts [type-body-stmts]
"}") "}") stmtsep
type-body-stmts = numerical-restrictions / type-body-stmts = numerical-restrictions /
decimal64-specification / decimal64-specification /
string-restrictions / string-restrictions /
enum-specification / enum-specification /
leafref-specification / leafref-specification /
identityref-specification / identityref-specification /
instance-identifier-specification / instance-identifier-specification /
bits-specification / bits-specification /
union-specification / union-specification /
binary-specification binary-specification
numerical-restrictions = range-stmt stmtsep numerical-restrictions = range-stmt
range-stmt = range-keyword sep range-arg-str optsep range-stmt = range-keyword sep range-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[error-message-stmt stmtsep] [error-message-stmt]
[error-app-tag-stmt stmtsep] [error-app-tag-stmt]
[description-stmt stmtsep] [description-stmt]
[reference-stmt stmtsep] [reference-stmt]
"}") "}") stmtsep
decimal64-specification = ;; these stmts can appear in any order decimal64-specification = ;; these stmts can appear in any order
fraction-digits-stmt fraction-digits-stmt
[range-stmt stmtsep] [range-stmt]
fraction-digits-stmt = fraction-digits-keyword sep fraction-digits-stmt = fraction-digits-keyword sep
fraction-digits-arg-str stmtend fraction-digits-arg-str stmtend
fraction-digits-arg-str = < a string that matches the rule > fraction-digits-arg-str = < a string that matches the rule >
< fraction-digits-arg > < fraction-digits-arg >
fraction-digits-arg = ("1" ["0" / "1" / "2" / "3" / "4" / fraction-digits-arg = ("1" ["0" / "1" / "2" / "3" / "4" /
"5" / "6" / "7" / "8"]) "5" / "6" / "7" / "8"])
/ "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
string-restrictions = ;; these stmts can appear in any order string-restrictions = ;; these stmts can appear in any order
[length-stmt stmtsep] [length-stmt]
*(pattern-stmt stmtsep) *pattern-stmt
length-stmt = length-keyword sep length-arg-str optsep length-stmt = length-keyword sep length-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]
[error-app-tag-stmt stmtsep] [error-app-tag-stmt]
[description-stmt stmtsep] [description-stmt]
[reference-stmt stmtsep] [reference-stmt]
"}") stmtsep
"}")
pattern-stmt = pattern-keyword sep string optsep pattern-stmt = pattern-keyword sep string optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[modifier-stmt stmtsep] [modifier-stmt]
[error-message-stmt stmtsep] [error-message-stmt]
[error-app-tag-stmt stmtsep] [error-app-tag-stmt]
[description-stmt stmtsep] [description-stmt]
[reference-stmt stmtsep] [reference-stmt]
"}") "}") stmtsep
modifier-stmt = modifier-keyword sep modifier-arg-str stmtend modifier-stmt = modifier-keyword sep modifier-arg-str stmtend
modifier-arg-str = < a string that matches the rule > modifier-arg-str = < a string that matches the rule >
< modifier-arg > < modifier-arg >
modifier-arg = invert-match-keyword modifier-arg = invert-match-keyword
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
enum-stmt = enum-keyword sep string optsep enum-stmt = enum-keyword sep string optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
*(if-feature-stmt stmtsep) *if-feature-stmt
[value-stmt stmtsep] [value-stmt]
[status-stmt stmtsep] [status-stmt]
[description-stmt stmtsep] [description-stmt]
[reference-stmt stmtsep] [reference-stmt]
"}") "}") stmtsep
leafref-specification = leafref-specification =
;; these stmts can appear in any order ;; these stmts can appear in any order
path-stmt stmtsep path-stmt
[require-instance-stmt stmtsep] [require-instance-stmt]
path-stmt = path-keyword sep path-arg-str stmtend path-stmt = path-keyword sep path-arg-str stmtend
require-instance-stmt = require-instance-keyword sep require-instance-stmt = require-instance-keyword sep
require-instance-arg-str stmtend require-instance-arg-str stmtend
require-instance-arg-str = < a string that matches the rule > require-instance-arg-str = < a string that matches the rule >
< require-instance-arg > < require-instance-arg >
require-instance-arg = true-keyword / false-keyword require-instance-arg = true-keyword / false-keyword
instance-identifier-specification = instance-identifier-specification =
[require-instance-stmt stmtsep]
[require-instance-stmt]
identityref-specification = identityref-specification =
1*(base-stmt stmtsep) 1*base-stmt
union-specification = 1*(type-stmt stmtsep) union-specification = 1*type-stmt
binary-specification = [length-stmt stmtsep] binary-specification = [length-stmt]
bits-specification = 1*(bit-stmt stmtsep) bits-specification = 1*bit-stmt
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
*(if-feature-stmt stmtsep) *if-feature-stmt
[position-stmt stmtsep] [position-stmt]
[status-stmt stmtsep] [status-stmt]
[description-stmt stmtsep] [description-stmt]
[reference-stmt stmtsep] [reference-stmt]
"}") "}") stmtsep
position-stmt = position-keyword sep position-stmt = position-keyword sep
position-value-arg-str stmtend position-value-arg-str stmtend
position-value-arg-str = < a string that matches the rule > position-value-arg-str = < a string that matches the rule >
< position-value-arg > < position-value-arg >
position-value-arg = non-negative-integer-value position-value-arg = non-negative-integer-value
status-stmt = status-keyword sep status-arg-str stmtend status-stmt = status-keyword sep status-arg-str stmtend
skipping to change at page 160, line 29 skipping to change at page 161, line 25
ordered-by-arg-str = < a string that matches the rule > ordered-by-arg-str = < a string that matches the rule >
< ordered-by-arg > < ordered-by-arg >
ordered-by-arg = user-keyword / system-keyword ordered-by-arg = user-keyword / system-keyword
must-stmt = must-keyword sep string optsep must-stmt = must-keyword sep string optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[error-message-stmt stmtsep] [error-message-stmt]
[error-app-tag-stmt stmtsep] [error-app-tag-stmt]
[description-stmt stmtsep] [description-stmt]
[reference-stmt stmtsep] [reference-stmt]
"}") "}") stmtsep
error-message-stmt = error-message-keyword sep string stmtend error-message-stmt = error-message-keyword sep string stmtend
error-app-tag-stmt = error-app-tag-keyword sep string stmtend error-app-tag-stmt = error-app-tag-keyword sep string stmtend
min-elements-stmt = min-elements-keyword sep min-elements-stmt = min-elements-keyword sep
min-value-arg-str stmtend min-value-arg-str stmtend
min-value-arg-str = < a string that matches the rule > min-value-arg-str = < a string that matches the rule >
< min-value-arg > < min-value-arg >
skipping to change at page 161, line 17 skipping to change at page 162, line 14
value-stmt = value-keyword sep integer-value-str stmtend value-stmt = value-keyword sep integer-value-str stmtend
integer-value-str = < a string that matches the rule > integer-value-str = < a string that matches the rule >
< integer-value > < integer-value >
grouping-stmt = grouping-keyword sep identifier-arg-str optsep grouping-stmt = grouping-keyword sep identifier-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[status-stmt stmtsep] [status-stmt]
[description-stmt stmtsep] [description-stmt]
[reference-stmt stmtsep] [reference-stmt]
*((typedef-stmt / *(typedef-stmt / grouping-stmt)
grouping-stmt) stmtsep) *data-def-stmt
*(data-def-stmt stmtsep) *action-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] [when-stmt]
*(if-feature-stmt stmtsep) *if-feature-stmt
*(must-stmt stmtsep) *must-stmt
[presence-stmt stmtsep] [presence-stmt]
[config-stmt stmtsep] [config-stmt]
[status-stmt stmtsep] [status-stmt]
[description-stmt stmtsep] [description-stmt]
[reference-stmt stmtsep] [reference-stmt]
*((typedef-stmt / *(typedef-stmt / grouping-stmt)
grouping-stmt) stmtsep) *data-def-stmt
*(data-def-stmt stmtsep) *action-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] [when-stmt]
*(if-feature-stmt stmtsep) *if-feature-stmt
type-stmt stmtsep type-stmt
[units-stmt stmtsep] [units-stmt]
*(must-stmt stmtsep) *must-stmt
[default-stmt stmtsep] [default-stmt]
[config-stmt stmtsep] [config-stmt]
[mandatory-stmt stmtsep] [mandatory-stmt]
[status-stmt]
[description-stmt]
[reference-stmt]
[status-stmt stmtsep] "}" stmtsep
[description-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] [when-stmt]
*(if-feature-stmt stmtsep) *if-feature-stmt
type-stmt stmtsep type-stmt stmtsep
[units-stmt stmtsep] [units-stmt]
*(must-stmt stmtsep) *must-stmt
*(default-stmt stmtsep) *default-stmt
[config-stmt stmtsep] [config-stmt]
[min-elements-stmt stmtsep] [min-elements-stmt]
[max-elements-stmt stmtsep] [max-elements-stmt]
[ordered-by-stmt stmtsep] [ordered-by-stmt]
[status-stmt stmtsep] [status-stmt]
[description-stmt stmtsep] [description-stmt]
[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] [when-stmt]
*(if-feature-stmt stmtsep) *if-feature-stmt
*(must-stmt stmtsep) *must-stmt
[key-stmt stmtsep] [key-stmt]
*(unique-stmt stmtsep) *unique-stmt
[config-stmt stmtsep] [config-stmt]
[min-elements-stmt stmtsep] [min-elements-stmt]
[max-elements-stmt stmtsep] [max-elements-stmt]
[ordered-by-stmt stmtsep] [ordered-by-stmt]
[status-stmt stmtsep] [status-stmt]
[description-stmt stmtsep] [description-stmt]
[reference-stmt stmtsep] [reference-stmt]
*((typedef-stmt / *(typedef-stmt / grouping-stmt)
grouping-stmt) stmtsep) 1*data-def-stmt
1*(data-def-stmt stmtsep) *action-stmt
"}" "}" stmtsep
key-stmt = key-keyword sep key-arg-str stmtend key-stmt = key-keyword sep key-arg-str stmtend
key-arg-str = < a string that matches the rule > key-arg-str = < a string that matches the rule >
< key-arg > < key-arg >
key-arg = node-identifier *(sep node-identifier) key-arg = node-identifier *(sep node-identifier)
unique-stmt = unique-keyword sep unique-arg-str stmtend unique-stmt = unique-keyword sep unique-arg-str stmtend
unique-arg-str = < a string that matches the rule > unique-arg-str = < a string that 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
skipping to change at page 163, line 19 skipping to change at page 164, line 14
unique-arg-str = < a string that matches the rule > unique-arg-str = < a string that 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] [when-stmt]
*(if-feature-stmt stmtsep) *if-feature-stmt
[default-stmt stmtsep] [default-stmt]
[config-stmt stmtsep] [config-stmt]
[mandatory-stmt stmtsep] [mandatory-stmt]
[status-stmt stmtsep] [status-stmt]
[description-stmt stmtsep] [description-stmt]
[reference-stmt stmtsep] [reference-stmt]
*((short-case-stmt / case-stmt) stmtsep) *(short-case-stmt / case-stmt)
"}") "}") stmtsep
short-case-stmt = choice-stmt / short-case-stmt = choice-stmt /
container-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] [when-stmt]
*(if-feature-stmt stmtsep) *if-feature-stmt
[status-stmt stmtsep] [status-stmt]
[description-stmt stmtsep] [description-stmt]
[reference-stmt stmtsep] [reference-stmt]
*(data-def-stmt stmtsep) *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]
*if-feature-stmt
*must-stmt
[config-stmt]
[when-stmt stmtsep] [mandatory-stmt]
*(if-feature-stmt stmtsep) [status-stmt]
*(must-stmt stmtsep) [description-stmt]
[config-stmt stmtsep] [reference-stmt]
[mandatory-stmt stmtsep] "}") stmtsep
[status-stmt stmtsep]
[description-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] [when-stmt]
*(if-feature-stmt stmtsep) *if-feature-stmt
[status-stmt stmtsep] [status-stmt]
[description-stmt stmtsep] [description-stmt]
[reference-stmt stmtsep] [reference-stmt]
*(refine-stmt stmtsep) *refine-stmt
*(uses-augment-stmt stmtsep) *uses-augment-stmt
"}") "}") stmtsep
refine-stmt = refine-keyword sep refine-arg-str optsep refine-stmt = refine-keyword sep refine-arg-str optsep
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
*(if-feature-stmt stmtsep) *if-feature-stmt
*(must-stmt stmtsep) *must-stmt
[presence-stmt stmtsep] [presence-stmt]
[default-stmt stmtsep] [default-stmt]
[config-stmt stmtsep] [config-stmt]
[mandatory-stmt stmtsep] [mandatory-stmt]
[min-elements-stmt stmtsep] [min-elements-stmt]
[max-elements-stmt stmtsep] [max-elements-stmt]
[description-stmt stmtsep] [description-stmt]
[reference-stmt stmtsep] [reference-stmt]
"}" "}" stmtsep
refine-arg-str = < a string that matches the rule > refine-arg-str = < a string that matches the rule >
< refine-arg > < refine-arg >
refine-arg = descendant-schema-nodeid refine-arg = descendant-schema-nodeid
uses-augment-stmt = augment-keyword sep uses-augment-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
[when-stmt stmtsep] [when-stmt]
*(if-feature-stmt stmtsep) *if-feature-stmt
[status-stmt]
[description-stmt]
[reference-stmt]
1*(data-def-stmt / case-stmt / action-stmt)
[status-stmt stmtsep] "}" stmtsep
[description-stmt stmtsep]
[reference-stmt stmtsep]
1*((data-def-stmt stmtsep) /
(case-stmt stmtsep))
"}"
uses-augment-arg-str = < a string that matches the rule > uses-augment-arg-str = < a string that matches the rule >
< uses-augment-arg > < uses-augment-arg >
uses-augment-arg = descendant-schema-nodeid 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]
*(if-feature-stmt stmtsep) *if-feature-stmt
[status-stmt stmtsep] [status-stmt]
[description-stmt stmtsep] [description-stmt]
[reference-stmt stmtsep] [reference-stmt]
1*((data-def-stmt stmtsep) / 1*(data-def-stmt / case-stmt / action-stmt)
(case-stmt stmtsep)) "}" stmtsep
"}"
augment-arg-str = < a string that matches the rule > augment-arg-str = < a string that matches the rule >
< augment-arg > < augment-arg >
augment-arg = absolute-schema-nodeid augment-arg = absolute-schema-nodeid
when-stmt = when-keyword sep string optsep when-stmt = when-keyword sep string optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[description-stmt stmtsep] [description-stmt]
[reference-stmt stmtsep] [reference-stmt]
"}") "}") stmtsep
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) *if-feature-stmt
[status-stmt stmtsep] [status-stmt]
[description-stmt stmtsep] [description-stmt]
[reference-stmt stmtsep] [reference-stmt]
*((typedef-stmt / *(typedef-stmt / grouping-stmt)
grouping-stmt) stmtsep) [input-stmt]
[input-stmt stmtsep] [output-stmt]
"}") stmtsep
[output-stmt stmtsep] action-stmt = action-keyword sep identifier-arg-str optsep
"}") (";" /
"{" stmtsep
;; these stmts can appear in any order
*if-feature-stmt
[status-stmt]
[description-stmt]
[reference-stmt]
*(typedef-stmt / grouping-stmt)
[input-stmt]
[output-stmt]
"}") stmtsep
input-stmt = input-keyword optsep input-stmt = input-keyword optsep
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
*(must-stmt stmtsep) *must-stmt
*((typedef-stmt / *(typedef-stmt / grouping-stmt)
grouping-stmt) stmtsep) 1*data-def-stmt
1*(data-def-stmt stmtsep) "}" stmtsep
"}"
output-stmt = output-keyword optsep output-stmt = output-keyword optsep
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
*(must-stmt stmtsep) *must-stmt
*((typedef-stmt / *(typedef-stmt / grouping-stmt)
grouping-stmt) stmtsep) 1*data-def-stmt
1*(data-def-stmt stmtsep) "}" 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) *if-feature-stmt
*(must-stmt stmtsep) *must-stmt
[status-stmt stmtsep] [status-stmt]
[description-stmt stmtsep] [description-stmt]
[reference-stmt stmtsep] [reference-stmt]
*((typedef-stmt / *(typedef-stmt / grouping-stmt)
grouping-stmt) stmtsep) *data-def-stmt
*(data-def-stmt stmtsep) "}") stmtsep
"}")
deviation-stmt = deviation-keyword sep deviation-stmt = deviation-keyword sep
deviation-arg-str optsep deviation-arg-str optsep
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[description-stmt stmtsep] [description-stmt]
[reference-stmt stmtsep] [reference-stmt]
(deviate-not-supported-stmt / (deviate-not-supported-stmt /
1*(deviate-add-stmt / 1*(deviate-add-stmt /
deviate-replace-stmt / deviate-replace-stmt /
deviate-delete-stmt)) deviate-delete-stmt))
"}" "}" stmtsep
deviation-arg-str = < a string that matches the rule > deviation-arg-str = < a string that matches the rule >
< deviation-arg > < deviation-arg >
deviation-arg = absolute-schema-nodeid deviation-arg = absolute-schema-nodeid
deviate-not-supported-stmt = deviate-not-supported-stmt =
deviate-keyword sep deviate-keyword sep
not-supported-keyword-str optsep not-supported-keyword-str stmtend
(";" /
"{" stmtsep
"}")
deviate-add-stmt = deviate-keyword sep add-keyword-str optsep deviate-add-stmt = deviate-keyword sep add-keyword-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[units-stmt stmtsep] [units-stmt]
*(must-stmt stmtsep) *must-stmt
*(unique-stmt stmtsep) *unique-stmt
[default-stmt stmtsep] [default-stmt]
[config-stmt stmtsep] [config-stmt]
[mandatory-stmt stmtsep] [mandatory-stmt]
[min-elements-stmt stmtsep] [min-elements-stmt]
[max-elements-stmt stmtsep] [max-elements-stmt]
"}") "}") stmtsep
deviate-delete-stmt = deviate-keyword sep delete-keyword-str optsep deviate-delete-stmt = deviate-keyword sep delete-keyword-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[units-stmt stmtsep] [units-stmt]
*(must-stmt stmtsep) *must-stmt
*(unique-stmt stmtsep) *unique-stmt
[default-stmt stmtsep] [default-stmt]
"}") "}") stmtsep
deviate-replace-stmt = deviate-keyword sep replace-keyword-str optsep deviate-replace-stmt = deviate-keyword sep replace-keyword-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[type-stmt stmtsep] [type-stmt]
[units-stmt stmtsep] [units-stmt]
[default-stmt stmtsep] [default-stmt]
[config-stmt stmtsep] [config-stmt]
[mandatory-stmt stmtsep] [mandatory-stmt]
[min-elements-stmt stmtsep] [min-elements-stmt]
[max-elements-stmt stmtsep] [max-elements-stmt]
"}") "}") stmtsep
not-supported-keyword-str = < a string that matches the rule > not-supported-keyword-str = < a string that matches the rule >
< not-supported-keyword> < not-supported-keyword >
add-keyword-str = < a string that matches the rule > add-keyword-str = < a string that matches the rule >
< add-keyword > < add-keyword >
delete-keyword-str = < a string that matches the rule > delete-keyword-str = < a string that matches the rule >
< delete-keyword > < delete-keyword >
replace-keyword-str = < a string that matches the rule > replace-keyword-str = < a string that matches the rule >
< replace-keyword > < replace-keyword >
;; represents the usage of an extension statement ;; represents the usage of an extension statement
unknown-statement = prefix ":" identifier [sep string] optsep unknown-statement = prefix ":" identifier [sep string] optsep
(";" / (";" /
"{" optsep "{" optsep
*((yang-stmt / unknown-statement) optsep) *((yang-stmt / unknown-statement) optsep)
"}") "}") stmtsep
yang-stmt = anyxml-stmt / yang-stmt = action-stmt /
anyxml-stmt /
argument-stmt / argument-stmt /
augment-stmt / augment-stmt /
base-stmt / base-stmt /
belongs-to-stmt / belongs-to-stmt /
bit-stmt / bit-stmt /
case-stmt / case-stmt /
choice-stmt / choice-stmt /
config-stmt / config-stmt /
contact-stmt / contact-stmt /
container-stmt / container-stmt /
skipping to change at page 171, line 36 skipping to change at page 172, line 38
path-key-expr = current-function-invocation *WSP "/" *WSP path-key-expr = current-function-invocation *WSP "/" *WSP
rel-path-keyexpr rel-path-keyexpr
rel-path-keyexpr = 1*(".." *WSP "/" *WSP) rel-path-keyexpr = 1*(".." *WSP "/" *WSP)
*(node-identifier *WSP "/" *WSP) *(node-identifier *WSP "/" *WSP)
node-identifier node-identifier
;;; Keywords, using RFC 7405 syntax for case-sensitive strings ;;; Keywords, using RFC 7405 syntax for case-sensitive strings
;; statement keywords ;; statement keywords
action-keyword = %s"action"
anyxml-keyword = %s"anyxml" anyxml-keyword = %s"anyxml"
argument-keyword = %s"argument" argument-keyword = %s"argument"
augment-keyword = %s"augment" augment-keyword = %s"augment"
base-keyword = %s"base" base-keyword = %s"base"
belongs-to-keyword = %s"belongs-to" belongs-to-keyword = %s"belongs-to"
bit-keyword = %s"bit" bit-keyword = %s"bit"
case-keyword = %s"case" case-keyword = %s"case"
choice-keyword = %s"choice" choice-keyword = %s"choice"
config-keyword = %s"config" config-keyword = %s"config"
contact-keyword = %s"contact" contact-keyword = %s"contact"
skipping to change at page 174, line 5 skipping to change at page 175, line 8
identifier-arg = identifier identifier-arg = identifier
;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l')) ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l'))
identifier = (ALPHA / "_") identifier = (ALPHA / "_")
*(ALPHA / DIGIT / "_" / "-" / ".") *(ALPHA / DIGIT / "_" / "-" / ".")
identifier-ref-arg-str = < a string that matches the rule > identifier-ref-arg-str = < a string that matches the rule >
< identifier-ref-arg > < identifier-ref-arg >
identifier-ref-arg = [prefix ":"] identifier identifier-ref-arg = identifier-ref
identifier-ref = [prefix ":"] identifier
string = < an unquoted string as returned by > string = < an unquoted string as returned by >
< the scanner, that matches the rule > < the scanner, that matches the rule >
< yang-string > < yang-string >
yang-string = *yang-char yang-string = *yang-char
;; any Unicode character including tab, carriage return, and line ;; any Unicode character including tab, carriage return, and line
;; feed, but excluding the other C0 control characters, the surrogate ;; feed, but excluding the other C0 control characters, the surrogate
;; blocks, and the noncharacters. ;; blocks, and the noncharacters.
skipping to change at page 174, line 46 skipping to change at page 175, line 51
integer-value = ("-" non-negative-integer-value) / integer-value = ("-" non-negative-integer-value) /
non-negative-integer-value non-negative-integer-value
non-negative-integer-value = "0" / positive-integer-value non-negative-integer-value = "0" / positive-integer-value
positive-integer-value = (non-zero-digit *DIGIT) positive-integer-value = (non-zero-digit *DIGIT)
zero-integer-value = 1*DIGIT zero-integer-value = 1*DIGIT
stmtend = ";" / "{" *unknown-statement "}" stmtend = optsep (";" / "{" stmtsep "}") stmtsep
sep = 1*(WSP / line-break) sep = 1*(WSP / line-break)
; unconditional separator ; unconditional separator
optsep = *(WSP / line-break) optsep = *(WSP / line-break)
stmtsep = *(WSP / line-break / unknown-statement) stmtsep = *(WSP / line-break / unknown-statement)
line-break = CRLF / LF line-break = CRLF / LF
non-zero-digit = %x31-39 non-zero-digit = %x31-39
decimal-value = integer-value ("." zero-integer-value) decimal-value = integer-value ("." zero-integer-value)
SQUOTE = %x27 SQUOTE = %x27
; ' (Single Quote) ; ' (Single Quote)
skipping to change at page 179, line 12 skipping to change at page 180, line 12
in the IETF XML registry [RFC3688]. Following the format in RFC in the IETF XML registry [RFC3688]. Following the format in RFC
3688, the following have been registered. 3688, the following have been registered.
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
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URIs are XML namespaces. XML: N/A, the requested URIs are XML namespaces.
This document registers one capability identifier URN from the
"Network Configuration Protocol (NETCONF) Capability URNs" registry:
urn:ietf:params:netconf:capability:yang-library:1.0
This document registers two new media types as defined in the This document registers two new media types as defined in the
following sections. following sections.
15.1. Media type application/yang 15.1. Media type application/yang
MIME media type name: application MIME media type name: application
MIME subtype name: yang MIME subtype name: yang
Mandatory parameters: none Mandatory parameters: none
skipping to change at page 183, line 17 skipping to change at page 184, line 17
The editor wishes to thank the following individuals, who all The editor wishes to thank the following individuals, who all
provided helpful comments on various versions of this document: provided helpful comments on various versions of this document:
Mehmet Ersue, Washam Fan, Joel Halpern, Leif Johansson, Ladislav Mehmet Ersue, Washam Fan, Joel Halpern, Leif Johansson, Ladislav
Lhotka, Gerhard Muenz, Tom Petch, Randy Presuhn, David Reid, and Bert Lhotka, Gerhard Muenz, Tom Petch, Randy Presuhn, David Reid, and Bert
Wijnen. Wijnen.
19. ChangeLog 19. ChangeLog
RFC Editor: remove this section upon publication as an RFC. RFC Editor: remove this section upon publication as an RFC.
19.1. Version -03 19.1. Version -04
o Incorporated changes to ABNF grammar after review and errata for
RFC 6020.
o Included solution Y16-03.
o Included solution Y49-04.
o Included solution Y58-01.
o Included solution Y59-01.
19.2. Version -03
o Incorporated changes from WG reviews. o Incorporated changes from WG reviews.
o Included solution Y05-01. o Included solution Y05-01.
o Included solution Y10-01. o Included solution Y10-01.
o Included solution Y13-01. o Included solution Y13-01.
o Included solution Y28-02. o Included solution Y28-02.
o Included solution Y55-01 (parts of it was included in -01). o Included solution Y55-01 (parts of it was included in -01).
19.2. Version -02 19.3. Version -02
o Included solution Y02-01. o Included solution Y02-01.
o Included solution Y04-02. o Included solution Y04-02.
o Included solution Y11-01. o Included solution Y11-01.
o Included solution Y41-01. o Included solution Y41-01.
o Included solution Y56-01. o Included solution Y56-01.
19.3. Version -01 19.4. Version -01
o Included solution Y01-01. o Included solution Y01-01.
o Included solution Y03-01. o Included solution Y03-01.
o Included solution Y06-02. o Included solution Y06-02.
o Included solution Y07-01. o Included solution Y07-01.
o Included solution Y14-01. o Included solution Y14-01.
skipping to change at page 184, line 19 skipping to change at page 185, line 31
o Included solution Y23-01. o Included solution Y23-01.
o Included solution Y29-01. o Included solution Y29-01.
o Included solution Y30-01. o Included solution Y30-01.
o Included solution Y31-01. o Included solution Y31-01.
o Included solution Y35-01. o Included solution Y35-01.
19.4. Version -00 19.5. Version -00
o Applied all reported errata for RFC 6020. o Applied all reported errata for RFC 6020.
o Updated YANG version to 1.1, and made the "yang-version" statement o Updated YANG version to 1.1, and made the "yang-version" statement
mandatory. mandatory.
20. References 20. References
20.1. Normative References 20.1. Normative References
[I-D.ietf-netconf-yang-library]
Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
Library", draft-ietf-netconf-yang-library (work in
progress), January 2015.
[ISO.10646] [ISO.10646]
International Organization for Standardization, International Organization for Standardization,
"Information Technology - Universal Multiple-Octet Coded "Information Technology - Universal Multiple-Octet Coded
Character Set (UCS)", ISO Standard 10646:2003, 2003. Character Set (UCS)", ISO Standard 10646:2003, 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
 End of changes. 259 change blocks. 
898 lines changed or deleted 1014 lines changed or added

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