draft-ietf-netmod-rfc6020bis-00.txt   draft-ietf-netmod-rfc6020bis-01.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) July 3, 2014 Obsoletes: 6020 (if approved) October 2, 2014
Intended status: Standards Track Intended status: Standards Track
Expires: January 4, 2015 Expires: April 5, 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-00 draft-ietf-netmod-rfc6020bis-01
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 January 4, 2015. This Internet-Draft will expire on April 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Mandatory Nodes . . . . . . . . . . . . . . . . . . . . . 11 3.1. Mandatory Nodes . . . . . . . . . . . . . . . . . . . . . 11
4. YANG Overview . . . . . . . . . . . . . . . . . . . . . . . . 11 4. YANG Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Functional Overview . . . . . . . . . . . . . . . . . . . 11 4.1. Functional Overview . . . . . . . . . . . . . . . . . . . 12
4.2. Language Overview . . . . . . . . . . . . . . . . . . . . 13 4.2. Language Overview . . . . . . . . . . . . . . . . . . . . 13
4.2.1. Modules and Submodules . . . . . . . . . . . . . . . 13 4.2.1. Modules and Submodules . . . . . . . . . . . . . . . 14
4.2.2. Data Modeling Basics . . . . . . . . . . . . . . . . 13 4.2.2. Data Modeling Basics . . . . . . . . . . . . . . . . 14
4.2.3. State Data . . . . . . . . . . . . . . . . . . . . . 18 4.2.3. State Data . . . . . . . . . . . . . . . . . . . . . 18
4.2.4. Built-In Types . . . . . . . . . . . . . . . . . . . 18 4.2.4. Built-In Types . . . . . . . . . . . . . . . . . . . 18
4.2.5. Derived Types (typedef) . . . . . . . . . . . . . . . 19 4.2.5. Derived Types (typedef) . . . . . . . . . . . . . . . 19
4.2.6. Reusable Node Groups (grouping) . . . . . . . . . . . 20 4.2.6. Reusable Node Groups (grouping) . . . . . . . . . . . 20
4.2.7. Choices . . . . . . . . . . . . . . . . . . . . . . . 21 4.2.7. Choices . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.8. Extending Data Models (augment) . . . . . . . . . . . 22 4.2.8. Extending Data Models (augment) . . . . . . . . . . . 22
4.2.9. RPC Definitions . . . . . . . . . . . . . . . . . . . 23 4.2.9. RPC Definitions . . . . . . . . . . . . . . . . . . . 23
4.2.10. Notification Definitions . . . . . . . . . . . . . . 24 4.2.10. Notification Definitions . . . . . . . . . . . . . . 24
5. Language Concepts . . . . . . . . . . . . . . . . . . . . . . 25 5. Language Concepts . . . . . . . . . . . . . . . . . . . . . . 25
5.1. Modules and Submodules . . . . . . . . . . . . . . . . . 25 5.1. Modules and Submodules . . . . . . . . . . . . . . . . . 25
skipping to change at page 4, line 35 skipping to change at page 4, line 35
7.8.2. The list's key Statement . . . . . . . . . . . . . . 68 7.8.2. The list's key Statement . . . . . . . . . . . . . . 68
7.8.3. The list's unique Statement . . . . . . . . . . . . . 69 7.8.3. The list's unique Statement . . . . . . . . . . . . . 69
7.8.4. The list's Child Node Statements . . . . . . . . . . 70 7.8.4. The list's Child Node Statements . . . . . . . . . . 70
7.8.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 70 7.8.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 70
7.8.6. NETCONF <edit-config> Operations . . . . . . . . . . 71 7.8.6. NETCONF <edit-config> Operations . . . . . . . . . . 71
7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 72 7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 72
7.9. The choice Statement . . . . . . . . . . . . . . . . . . 75 7.9. The choice Statement . . . . . . . . . . . . . . . . . . 75
7.9.1. The choice's Substatements . . . . . . . . . . . . . 75 7.9.1. The choice's Substatements . . . . . . . . . . . . . 75
7.9.2. The choice's case Statement . . . . . . . . . . . . . 76 7.9.2. The choice's case Statement . . . . . . . . . . . . . 76
7.9.3. The choice's default Statement . . . . . . . . . . . 77 7.9.3. The choice's default Statement . . . . . . . . . . . 77
7.9.4. The choice's mandatory Statement . . . . . . . . . . 78 7.9.4. The choice's mandatory Statement . . . . . . . . . . 79
7.9.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 79 7.9.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 79
7.9.6. NETCONF <edit-config> Operations . . . . . . . . . . 79 7.9.6. NETCONF <edit-config> Operations . . . . . . . . . . 79
7.9.7. Usage Example . . . . . . . . . . . . . . . . . . . . 79 7.9.7. Usage Example . . . . . . . . . . . . . . . . . . . . 79
7.10. The anyxml Statement . . . . . . . . . . . . . . . . . . 80 7.10. The anyxml Statement . . . . . . . . . . . . . . . . . . 80
7.10.1. The anyxml's Substatements . . . . . . . . . . . . . 81 7.10.1. The anyxml's Substatements . . . . . . . . . . . . . 81
7.10.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 81 7.10.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 81
7.10.3. NETCONF <edit-config> Operations . . . . . . . . . . 81 7.10.3. NETCONF <edit-config> Operations . . . . . . . . . . 81
7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . 82 7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . 82
7.11. The grouping Statement . . . . . . . . . . . . . . . . . 82 7.11. The grouping Statement . . . . . . . . . . . . . . . . . 82
7.11.1. The grouping's Substatements . . . . . . . . . . . . 83 7.11.1. The grouping's Substatements . . . . . . . . . . . . 83
skipping to change at page 5, line 30 skipping to change at page 5, line 30
7.16.1. The identity's Substatements . . . . . . . . . . . . 95 7.16.1. The identity's Substatements . . . . . . . . . . . . 95
7.16.2. The base Statement . . . . . . . . . . . . . . . . . 96 7.16.2. The base Statement . . . . . . . . . . . . . . . . . 96
7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . 96 7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . 96
7.17. The extension Statement . . . . . . . . . . . . . . . . . 97 7.17. The extension Statement . . . . . . . . . . . . . . . . . 97
7.17.1. The extension's Substatements . . . . . . . . . . . 98 7.17.1. The extension's Substatements . . . . . . . . . . . 98
7.17.2. The argument Statement . . . . . . . . . . . . . . . 98 7.17.2. The argument Statement . . . . . . . . . . . . . . . 98
7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . 99 7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . 99
7.18. Conformance-Related Statements . . . . . . . . . . . . . 99 7.18. Conformance-Related Statements . . . . . . . . . . . . . 99
7.18.1. The feature Statement . . . . . . . . . . . . . . . 99 7.18.1. The feature Statement . . . . . . . . . . . . . . . 99
7.18.2. The if-feature Statement . . . . . . . . . . . . . . 101 7.18.2. The if-feature Statement . . . . . . . . . . . . . . 101
7.18.3. The deviation Statement . . . . . . . . . . . . . . 101 7.18.3. The deviation Statement . . . . . . . . . . . . . . 102
7.19. Common Statements . . . . . . . . . . . . . . . . . . . . 104 7.19. Common Statements . . . . . . . . . . . . . . . . . . . . 104
7.19.1. The config Statement . . . . . . . . . . . . . . . . 104 7.19.1. The config Statement . . . . . . . . . . . . . . . . 104
7.19.2. The status Statement . . . . . . . . . . . . . . . . 104 7.19.2. The status Statement . . . . . . . . . . . . . . . . 105
7.19.3. The description Statement . . . . . . . . . . . . . 105 7.19.3. The description Statement . . . . . . . . . . . . . 106
7.19.4. The reference Statement . . . . . . . . . . . . . . 105 7.19.4. The reference Statement . . . . . . . . . . . . . . 106
7.19.5. The when Statement . . . . . . . . . . . . . . . . . 106 7.19.5. The when Statement . . . . . . . . . . . . . . . . . 106
8. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 107 8. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 108
8.1. Constraints on Data . . . . . . . . . . . . . . . . . . . 107 8.1. Constraints on Data . . . . . . . . . . . . . . . . . . . 108
8.2. Hierarchy of Constraints . . . . . . . . . . . . . . . . 107 8.2. Hierarchy of Constraints . . . . . . . . . . . . . . . . 108
8.3. Constraint Enforcement Model . . . . . . . . . . . . . . 108 8.3. Constraint Enforcement Model . . . . . . . . . . . . . . 108
8.3.1. Payload Parsing . . . . . . . . . . . . . . . . . . . 108 8.3.1. Payload Parsing . . . . . . . . . . . . . . . . . . . 109
8.3.2. NETCONF <edit-config> Processing . . . . . . . . . . 109 8.3.2. NETCONF <edit-config> Processing . . . . . . . . . . 109
8.3.3. Validation . . . . . . . . . . . . . . . . . . . . . 109 8.3.3. Validation . . . . . . . . . . . . . . . . . . . . . 110
9. Built-In Types . . . . . . . . . . . . . . . . . . . . . . . 110 9. Built-In Types . . . . . . . . . . . . . . . . . . . . . . . 110
9.1. Canonical Representation . . . . . . . . . . . . . . . . 110 9.1. Canonical Representation . . . . . . . . . . . . . . . . 111
9.2. The Integer Built-In Types . . . . . . . . . . . . . . . 111 9.2. The Integer Built-In Types . . . . . . . . . . . . . . . 111
9.2.1. Lexical Representation . . . . . . . . . . . . . . . 111 9.2.1. Lexical Representation . . . . . . . . . . . . . . . 112
9.2.2. Canonical Form . . . . . . . . . . . . . . . . . . . 112 9.2.2. Canonical Form . . . . . . . . . . . . . . . . . . . 112
9.2.3. Restrictions . . . . . . . . . . . . . . . . . . . . 112 9.2.3. Restrictions . . . . . . . . . . . . . . . . . . . . 113
9.2.4. The range Statement . . . . . . . . . . . . . . . . . 112 9.2.4. The range Statement . . . . . . . . . . . . . . . . . 113
9.2.5. Usage Example . . . . . . . . . . . . . . . . . . . . 113 9.2.5. Usage Example . . . . . . . . . . . . . . . . . . . . 113
9.3. The decimal64 Built-In Type . . . . . . . . . . . . . . . 113 9.3. The decimal64 Built-In Type . . . . . . . . . . . . . . . 114
9.3.1. Lexical Representation . . . . . . . . . . . . . . . 113 9.3.1. Lexical Representation . . . . . . . . . . . . . . . 114
9.3.2. Canonical Form . . . . . . . . . . . . . . . . . . . 114 9.3.2. Canonical Form . . . . . . . . . . . . . . . . . . . 114
9.3.3. Restrictions . . . . . . . . . . . . . . . . . . . . 114 9.3.3. Restrictions . . . . . . . . . . . . . . . . . . . . 115
9.3.4. The fraction-digits Statement . . . . . . . . . . . . 114 9.3.4. The fraction-digits Statement . . . . . . . . . . . . 115
9.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 115 9.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 115
9.4. The string Built-In Type . . . . . . . . . . . . . . . . 115 9.4. The string Built-In Type . . . . . . . . . . . . . . . . 116
9.4.1. Lexical Representation . . . . . . . . . . . . . . . 115 9.4.1. Lexical Representation . . . . . . . . . . . . . . . 116
9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 115 9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 116
9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 115 9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 116
9.4.4. The length Statement . . . . . . . . . . . . . . . . 115 9.4.4. The length Statement . . . . . . . . . . . . . . . . 116
9.4.5. Usage Example . . . . . . . . . . . . . . . . . . . . 116 9.4.5. The pattern Statement . . . . . . . . . . . . . . . . 117
9.4.6. The pattern Statement . . . . . . . . . . . . . . . . 117 9.4.6. The modifier Statement . . . . . . . . . . . . . . . 118
9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 117 9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 118
9.5. The boolean Built-In Type . . . . . . . . . . . . . . . . 118 9.5. The boolean Built-In Type . . . . . . . . . . . . . . . . 119
9.5.1. Lexical Representation . . . . . . . . . . . . . . . 118 9.5.1. Lexical Representation . . . . . . . . . . . . . . . 119
9.5.2. Canonical Form . . . . . . . . . . . . . . . . . . . 118 9.5.2. Canonical Form . . . . . . . . . . . . . . . . . . . 119
9.5.3. Restrictions . . . . . . . . . . . . . . . . . . . . 118 9.5.3. Restrictions . . . . . . . . . . . . . . . . . . . . 119
9.6. The enumeration Built-In Type . . . . . . . . . . . . . . 118 9.6. The enumeration Built-In Type . . . . . . . . . . . . . . 119
9.6.1. Lexical Representation . . . . . . . . . . . . . . . 118 9.6.1. Lexical Representation . . . . . . . . . . . . . . . 119
9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 118 9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 120
9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 118 9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 120
9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 118 9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 120
9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 119 9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 121
9.7. The bits Built-In Type . . . . . . . . . . . . . . . . . 120 9.7. The bits Built-In Type . . . . . . . . . . . . . . . . . 121
9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 120 9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 121
9.7.2. Lexical Representation . . . . . . . . . . . . . . . 120 9.7.2. Lexical Representation . . . . . . . . . . . . . . . 121
9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 120 9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 121
9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 120 9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 121
9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 121 9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 122
9.8. The binary Built-In Type . . . . . . . . . . . . . . . . 122 9.8. The binary Built-In Type . . . . . . . . . . . . . . . . 123
9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 122 9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 123
9.8.2. Lexical Representation . . . . . . . . . . . . . . . 122 9.8.2. Lexical Representation . . . . . . . . . . . . . . . 123
9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 122 9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 123
9.9. The leafref Built-In Type . . . . . . . . . . . . . . . . 122 9.9. The leafref Built-In Type . . . . . . . . . . . . . . . . 123
9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 122 9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 124
9.9.2. The path Statement . . . . . . . . . . . . . . . . . 123 9.9.2. The path Statement . . . . . . . . . . . . . . . . . 124
9.9.3. Lexical Representation . . . . . . . . . . . . . . . 123 9.9.3. The require-instance Statement . . . . . . . . . . . 125
9.9.4. Canonical Form . . . . . . . . . . . . . . . . . . . 124 9.9.4. Lexical Representation . . . . . . . . . . . . . . . 125
9.9.5. Usage Example . . . . . . . . . . . . . . . . . . . . 124 9.9.5. Canonical Form . . . . . . . . . . . . . . . . . . . 125
9.10. The identityref Built-In Type . . . . . . . . . . . . . . 127 9.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 125
9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 127 9.10. The identityref Built-In Type . . . . . . . . . . . . . . 129
9.10.2. The identityref's base Statement . . . . . . . . . . 127 9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 129
9.10.3. Lexical Representation . . . . . . . . . . . . . . . 128 9.10.2. The identityref's base Statement . . . . . . . . . . 129
9.10.4. Canonical Form . . . . . . . . . . . . . . . . . . . 128 9.10.3. Lexical Representation . . . . . . . . . . . . . . . 130
9.10.5. Usage Example . . . . . . . . . . . . . . . . . . . 128 9.10.4. Canonical Form . . . . . . . . . . . . . . . . . . . 130
9.11. The empty Built-In Type . . . . . . . . . . . . . . . . . 129 9.10.5. Usage Example . . . . . . . . . . . . . . . . . . . 130
9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 129 9.11. The empty Built-In Type . . . . . . . . . . . . . . . . . 132
9.11.2. Lexical Representation . . . . . . . . . . . . . . . 129 9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 132
9.11.3. Canonical Form . . . . . . . . . . . . . . . . . . . 129 9.11.2. Lexical Representation . . . . . . . . . . . . . . . 132
9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 129 9.11.3. Canonical Form . . . . . . . . . . . . . . . . . . . 132
9.12. The union Built-In Type . . . . . . . . . . . . . . . . . 130 9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 132
9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 130 9.12. The union Built-In Type . . . . . . . . . . . . . . . . . 132
9.12.2. Lexical Representation . . . . . . . . . . . . . . . 130 9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 133
9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 131 9.12.2. Lexical Representation . . . . . . . . . . . . . . . 133
9.13. The instance-identifier Built-In Type . . . . . . . . . . 131 9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 133
9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 132 9.12.4. Usage Example . . . . . . . . . . . . . . . . . . . 133
9.13.2. The require-instance Statement . . . . . . . . . . . 132 9.13. The instance-identifier Built-In Type . . . . . . . . . . 134
9.13.3. Lexical Representation . . . . . . . . . . . . . . . 132 9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 135
9.13.4. Canonical Form . . . . . . . . . . . . . . . . . . . 132 9.13.2. Lexical Representation . . . . . . . . . . . . . . . 135
9.13.5. Usage Example . . . . . . . . . . . . . . . . . . . 132 9.13.3. Canonical Form . . . . . . . . . . . . . . . . . . . 136
10. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 133 9.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 136
11. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 10. XPath Functions . . . . . . . . . . . . . . . . . . . . . . . 136
11.1. Formal YIN Definition . . . . . . . . . . . . . . . . . 136 10.1. Functions for Node Sets . . . . . . . . . . . . . . . . 136
11.1.1. Usage Example . . . . . . . . . . . . . . . . . . . 138 10.1.1. current() . . . . . . . . . . . . . . . . . . . . . 136
12. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 139 10.2. Functions for Strings . . . . . . . . . . . . . . . . . 137
13. Error Responses for YANG Related Errors . . . . . . . . . . . 161 10.2.1. re-match() . . . . . . . . . . . . . . . . . . . . . 137
13.1. Error Message for Data That Violates a unique Statement 161 10.3. Functions for the YANG Types "leafref" and "instance-
13.2. Error Message for Data That Violates a max-elements identifier" . . . . . . . . . . . . . . . . . . . . . . 137
Statement . . . . . . . . . . . . . . . . . . . . . . . 162 10.3.1. deref() . . . . . . . . . . . . . . . . . . . . . . 137
13.3. Error Message for Data That Violates a min-elements 10.4. Functions for the YANG Type "identityref" . . . . . . . 138
Statement . . . . . . . . . . . . . . . . . . . . . . . 162 10.4.1. derived-from() . . . . . . . . . . . . . . . . . . . 138
13.4. Error Message for Data That Violates a must Statement . 162 10.5. Functions for the YANG Type "enumeration" . . . . . . . 139
13.5. Error Message for Data That Violates a require-instance 10.5.1. enum-value() . . . . . . . . . . . . . . . . . . . . 139
Statement . . . . . . . . . . . . . . . . . . . . . . . 163 10.6. Functions for the YANG Type "bits" . . . . . . . . . . . 140
13.6. Error Message for Data That Does Not Match a leafref 10.6.1. bit-is-set() . . . . . . . . . . . . . . . . . . . . 140
Type . . . . . . . . . . . . . . . . . . . . . . . . . . 163 11. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 141
13.7. Error Message for Data That Violates a mandatory choice 12. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Statement . . . . . . . . . . . . . . . . . . . . . . . 163 12.1. Formal YIN Definition . . . . . . . . . . . . . . . . . 143
13.8. Error Message for the "insert" Operation . . . . . . . . 163 12.1.1. Usage Example . . . . . . . . . . . . . . . . . . . 146
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 164 13. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 147
14.1. Media type application/yang . . . . . . . . . . . . . . 165 14. Error Responses for YANG Related Errors . . . . . . . . . . . 170
14.2. Media type application/yin+xml . . . . . . . . . . . . . 165 14.1. Error Message for Data That Violates a unique Statement 170
15. Security Considerations . . . . . . . . . . . . . . . . . . . 167 14.2. Error Message for Data That Violates a max-elements
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 167 Statement . . . . . . . . . . . . . . . . . . . . . . . 170
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 168 14.3. Error Message for Data That Violates a min-elements
18. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Statement . . . . . . . . . . . . . . . . . . . . . . . 170
18.1. Version -00 . . . . . . . . . . . . . . . . . . . . . . 168 14.4. Error Message for Data That Violates a must Statement . 171
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 168 14.5. Error Message for Data That Violates a require-instance
19.1. Normative References . . . . . . . . . . . . . . . . . . 168 Statement . . . . . . . . . . . . . . . . . . . . . . . 171
19.2. Informative References . . . . . . . . . . . . . . . . . 169 14.6. Error Message for Data That Does Not Match a leafref
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 170 Type . . . . . . . . . . . . . . . . . . . . . . . . . . 171
14.7. Error Message for Data That Violates a mandatory choice
Statement . . . . . . . . . . . . . . . . . . . . . . . 171
14.8. Error Message for the "insert" Operation . . . . . . . . 172
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 172
15.1. Media type application/yang . . . . . . . . . . . . . . 173
15.2. Media type application/yin+xml . . . . . . . . . . . . . 174
16. Security Considerations . . . . . . . . . . . . . . . . . . . 176
17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 176
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 177
19. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 177
19.1. Version -01 . . . . . . . . . . . . . . . . . . . . . . 177
19.2. Version -00 . . . . . . . . . . . . . . . . . . . . . . 177
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 177
20.1. Normative References . . . . . . . . . . . . . . . . . . 178
20.2. Informative References . . . . . . . . . . . . . . . . . 179
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 179
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 8, line 28 skipping to change at page 8, line 39
1.1. Summary of Changes from RFC 6020 1.1. Summary of Changes from RFC 6020
This document defines version 1.1 of the YANG language. YANG version This document defines version 1.1 of the YANG language. YANG version
1.1 is a maintenance release of the YANG language, addressing 1.1 is a maintenance release of the YANG language, addressing
ambiguities and defects in the original specification [RFC6020]. ambiguities and defects in the original specification [RFC6020].
o Changed the YANG version from "1" to "1.1". o Changed the YANG version from "1" to "1.1".
o Made the "yang-version" statement mandatory. o Made the "yang-version" statement mandatory.
o Changed the rules for the interpretation of escaped characters in
double quoted strings. This is an backwards incompatible change
from YANG 1.0. A module that uses a character sequence that is
now illegal must change the string to match the new rules. See
Section 6.1.3 for details.
o Extended the "if-feature" syntax to be a boolean expression over
feature names.
o Added a set of new XPath functions in Section 10.
o Added a new substatement "modifier" to pattern (see
Section 9.4.6).
o Defined the string value of an identityref in XPath expressions
(see Section 9.10).
o Allow "if-feature" in "refine".
o Made "when" and "if-feature" illegal on list keys, unless the
parent is also conditional, and the condition matches the parent's
condition.
o Allow "choice" as a shorthand case statement (see Section 7.9).
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 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.
skipping to change at page 12, line 21 skipping to change at page 13, line 6
used in either that location or in another module or submodule that used in either that location or in another module or submodule that
imports or includes it. imports or includes it.
YANG data hierarchy constructs include defining lists where list YANG data hierarchy constructs include defining lists where list
entries are identified by keys that distinguish them from each other. entries are identified by keys that distinguish them from each other.
Such lists may be defined as either sorted by user or automatically Such lists may be defined as either sorted by user or automatically
sorted by the system. For user-sorted lists, operations are defined sorted by the system. For user-sorted lists, operations are defined
for manipulating the order of the list entries. for manipulating the order of the list entries.
YANG modules can be translated into an equivalent XML syntax called YANG modules can be translated into an equivalent XML syntax called
YANG Independent Notation (YIN) (Section 11), allowing applications YANG Independent Notation (YIN) (Section 12), allowing applications
using XML parsers and Extensible Stylesheet Language Transformations using XML parsers and Extensible Stylesheet Language Transformations
(XSLT) scripts to operate on the models. The conversion from YANG to (XSLT) scripts to operate on the models. The conversion from YANG to
YIN is lossless, so content in YIN can be round-tripped back into YIN is lossless, so content in YIN can be round-tripped back into
YANG. YANG.
YANG strikes a balance between high-level data modeling and low-level YANG strikes a balance between high-level data modeling and low-level
bits-on-the-wire encoding. The reader of a YANG module can see the bits-on-the-wire encoding. The reader of a YANG module can see the
high-level view of the data model while understanding how the data high-level view of the data model while understanding how the data
will be encoded in NETCONF operations. will be encoded in NETCONF operations.
skipping to change at page 21, line 39 skipping to change at page 21, line 39
4.2.7. Choices 4.2.7. Choices
YANG allows the data model to segregate incompatible nodes into YANG allows the data model to segregate incompatible nodes into
distinct choices using the "choice" and "case" statements. The distinct choices using the "choice" and "case" statements. The
"choice" statement contains a set of "case" statements that define "choice" statement contains a set of "case" statements that define
sets of schema nodes that cannot appear together. Each "case" may sets of schema nodes that cannot appear together. Each "case" may
contain multiple nodes, but each node may appear in only one "case" contain multiple nodes, but each node may appear in only one "case"
under a "choice". under a "choice".
When an element from one case is created, all elements from all other When a node from one case is created, all nodes from all other cases
cases are implicitly deleted. The device handles the enforcement of are implicitly deleted. The device handles the enforcement of the
the constraint, preventing incompatibilities from existing in the constraint, preventing incompatibilities from existing in the
configuration. configuration.
The choice and case nodes appear only in the schema tree, not in the The choice and case nodes appear only in the schema tree, not in the
data tree or NETCONF messages. The additional levels of hierarchy data tree or NETCONF messages. The additional levels of hierarchy
are not needed beyond the conceptual schema. are not needed beyond the conceptual schema.
YANG Example: YANG Example:
container food { container food {
choice snack { choice snack {
skipping to change at page 29, line 9 skipping to change at page 29, line 9
5.3. XML Namespaces 5.3. XML Namespaces
All YANG definitions are specified within a module that is bound to a All YANG definitions are specified within a module that is bound to a
particular XML namespace [XML-NAMES], which is a globally unique URI particular XML namespace [XML-NAMES], which is a globally unique URI
[RFC3986]. A NETCONF client or server uses the namespace during XML [RFC3986]. A NETCONF client or server uses the namespace during XML
encoding of data. encoding of data.
Namespaces for modules published in RFC streams [RFC4844] MUST be Namespaces for modules published in RFC streams [RFC4844] MUST be
assigned by IANA, see Section 14. assigned by IANA, see Section 15.
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
skipping to change at page 31, line 34 skipping to change at page 31, line 34
A module may declare any number of features, identified by simple A module may declare any number of features, identified by simple
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 with the name of the feature as its argument. "if-feature" statement.
Further details are available in Section 7.18.1. Further details are available in Section 7.18.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
skipping to change at page 35, line 43 skipping to change at page 35, line 43
Within a double-quoted string (enclosed within " "), a backslash Within a double-quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the character introduces a special character, which depends on the
character that immediately follows the backslash: character that immediately follows the backslash:
\n new line \n new line
\t a tab character \t a tab character
\" a double quote \" a double quote
\\ a single backslash \\ a single backslash
It is an error if any other character follows the backslash
character.
If a quoted string is followed by a plus character ("+"), followed by If a quoted string is followed by a plus character ("+"), followed by
another quoted string, the two strings are concatenated into one another quoted string, the two strings are concatenated into one
string, allowing multiple concatenations to build one string. string, allowing multiple concatenations to build one string.
Whitespace trimming and substitution of backslash-escaped characters Whitespace trimming and substitution of backslash-escaped characters
in double-quoted strings is done before concatenation. in double-quoted strings is done before concatenation.
6.1.3.1. Quoting Examples 6.1.3.1. Quoting Examples
The following strings are equivalent: The following strings are equivalent:
skipping to change at page 36, line 43 skipping to change at page 36, line 43
"first line\n" + " second line" "first line\n" + " second line"
6.2. Identifiers 6.2. Identifiers
Identifiers are used to identify different kinds of YANG items by Identifiers are used to identify different kinds of YANG items by
name. Each identifier starts with an uppercase or lowercase ASCII name. Each identifier starts with an uppercase or lowercase ASCII
letter or an underscore character, followed by zero or more ASCII letter or an underscore character, followed by zero or more ASCII
letters, digits, underscore characters, hyphens, and dots. letters, digits, underscore characters, hyphens, and dots.
Implementations MUST support identifiers up to 64 characters in Implementations MUST support identifiers up to 64 characters in
length. Identifiers are case sensitive. The identifier syntax is length. Identifiers are case sensitive. The identifier syntax is
formally defined by the rule "identifier" in Section 12. Identifiers formally defined by the rule "identifier" in Section 13. Identifiers
can be specified as quoted or unquoted strings. can be specified as quoted or unquoted strings.
6.2.1. Identifiers and Their Namespaces 6.2.1. Identifiers and Their Namespaces
Each identifier is valid in a namespace that depends on the type of Each identifier is valid in a namespace that depends on the type of
the YANG item being defined. All identifiers defined in a namespace the YANG item being defined. All identifiers defined in a namespace
MUST be unique. MUST be unique.
o All module and submodule names share the same global module o All module and submodule names share the same global module
identifier namespace. identifier namespace.
skipping to change at page 38, line 23 skipping to change at page 38, line 23
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 Since submodules cannot include the parent module, any extensions in
the module that need to be exposed to submodules MUST be defined in a the module that need to be exposed to submodules MUST be defined in a
submodule. Submodules can then include this submodule to find the submodule. Submodules can then include this submodule to find the
definition of the extension. 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 12), 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
data model are enforced. The manner of enforcement is an data model are enforced. The manner of enforcement is an
implementation decision. The XPath expressions MUST be syntactically implementation decision. The XPath expressions MUST be syntactically
skipping to change at page 39, line 11 skipping to change at page 39, line 11
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.
o Names without a namespace prefix belong to the same namespace as o Names without a namespace prefix belong to the same namespace as
the identifier of the current node. Inside a grouping, that the identifier of the current node. Inside a grouping, that
namespace is affected by where the grouping is used (see namespace is affected by where the grouping is used (see
Section 7.12). Section 7.12).
o The function library is the core function library defined in o The function library is the core function library defined in
[XPATH], and a function "current()" that returns a node set with [XPATH], and the functions defined in Section 10.
the initial context node.
o The set of variable bindings is empty. o The set of variable bindings is empty.
The mechanism for handling unprefixed names is adopted from XPath 2.0 The mechanism for handling unprefixed names is adopted from XPath 2.0
[XPATH2.0], and helps simplify XPath expressions in YANG. No [XPATH2.0], and helps simplify XPath expressions in YANG. No
ambiguity may ever arise because YANG node identifiers are always ambiguity may ever arise because YANG node identifiers are always
qualified names with a non-null namespace URI. qualified names with a non-null namespace URI.
The context node varies with the YANG XPath expression, and is The context node varies with the YANG XPath expression, and is
specified where the YANG statement with the XPath expression is specified where the YANG statement with the XPath expression is
defined. defined.
6.5. Schema Node Identifier 6.5. Schema Node Identifier
A schema node identifier is a string that identifies a node in the A schema node identifier is a string that identifies a node in the
schema tree. It has two forms, "absolute" and "descendant", defined schema tree. It has two forms, "absolute" and "descendant", defined
by the rules "absolute-schema-nodeid" and "descendant-schema-nodeid" by the rules "absolute-schema-nodeid" and "descendant-schema-nodeid"
in Section 12, respectively. A schema node identifier consists of a in Section 13, respectively. A schema node identifier consists of a
path of identifiers, separated by slashes ("/"). In an absolute path of identifiers, separated by slashes ("/"). In an absolute
schema node identifier, the first identifier after the leading slash schema node identifier, the first identifier after the leading slash
is any top-level schema node in the local module or in all imported is any top-level schema node in the local module or in all imported
modules. modules.
References to identifiers defined in external modules MUST be References to identifiers defined in external modules MUST be
qualified with appropriate prefixes, and references to identifiers qualified with appropriate prefixes, and references to identifiers
defined in the current module and its submodules MAY use a prefix. defined in the current module and its submodules MAY use a prefix.
For example, to identify the child node "b" of top-level node "a", For example, to identify the child node "b" of top-level node "a",
skipping to change at page 40, line 18 skipping to change at page 40, line 18
7.1. The module Statement 7.1. The module Statement
The "module" statement defines the module's name, and groups all The "module" statement defines the module's name, and groups all
statements that belong to the module together. The "module" statements that belong to the module together. The "module"
statement's argument is the name of the module, followed by a block statement's argument is the name of the module, followed by a block
of substatements that hold detailed module information. The module of substatements that hold detailed module information. The module
name follows the rules for identifiers in Section 6.2. name follows the rules for identifiers in Section 6.2.
Names of modules published in RFC streams [RFC4844] MUST be assigned Names of modules published in RFC streams [RFC4844] MUST be assigned
by IANA, see Section 14. by IANA, see Section 15.
Private module names are assigned by the organization owning the Private module names are assigned by the organization owning the
module without a central registry. It is RECOMMENDED to choose module without a central registry. It is RECOMMENDED to choose
module names that will have a low probability of colliding with module names that will have a low probability of colliding with
standard or other enterprise modules and submodules, e.g., by using standard or other enterprise modules and submodules, e.g., by using
the enterprise or organization name as a prefix for the module name. the enterprise or organization name as a prefix for the module name.
A module typically has the following layout: A module typically has the following layout:
module <module-name> { module <module-name> {
skipping to change at page 44, line 50 skipping to change at page 44, line 50
module should be sent, such as their name, postal address, telephone module should be sent, such as their name, postal address, telephone
number, and electronic mail address. number, and electronic mail address.
7.1.9. The revision Statement 7.1.9. The revision Statement
The "revision" statement specifies the editorial revision history of The "revision" statement specifies the editorial revision history of
the module, including the initial revision. A series of revision the module, including the initial revision. A series of revision
statements detail the changes in the module's definition. The statements detail the changes in the module's definition. The
argument is a date string in the format "YYYY-MM-DD", followed by a argument is a date string in the format "YYYY-MM-DD", followed by a
block of substatements that holds detailed revision information. A block of substatements that holds detailed revision information. A
module SHOULD have at least one initial "revision" statement. For module SHOULD have at least one "revision" statement. For every
every published editorial change, a new one SHOULD be added in front published editorial change, a new one SHOULD be added in front of the
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.19.3 | 0..1 |
| reference | 7.19.4 | 0..1 | | reference | 7.19.4 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
skipping to change at page 46, line 21 skipping to change at page 46, line 21
module that includes the submodules. module that includes the submodules.
The "submodule" statement defines the submodule's name, and groups The "submodule" statement defines the submodule's name, and groups
all statements that belong to the submodule together. The all statements that belong to the submodule together. The
"submodule" statement's argument is the name of the submodule, "submodule" statement's argument is the name of the submodule,
followed by a block of substatements that hold detailed submodule followed by a block of substatements that hold detailed submodule
information. The submodule name follows the rules for identifiers in information. The submodule name follows the rules for identifiers in
Section 6.2. Section 6.2.
Names of submodules published in RFC streams [RFC4844] MUST be Names of submodules published in RFC streams [RFC4844] MUST be
assigned by IANA, see Section 14. assigned by IANA, see Section 15.
Private submodule names are assigned by the organization owning the Private submodule names are assigned by the organization owning the
submodule without a central registry. It is RECOMMENDED to choose submodule without a central registry. It is RECOMMENDED to choose
submodule names that will have a low probability of colliding with submodule names that will have a low probability of colliding with
standard or other enterprise modules and submodules, e.g., by using standard or other enterprise modules and submodules, e.g., by using
the enterprise or organization name as a prefix for the submodule the enterprise or organization name as a prefix for the submodule
name. name.
A submodule typically has the following layout: A submodule typically has the following layout:
skipping to change at page 51, line 39 skipping to change at page 51, line 39
+------------------+---------+-------------+ +------------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+------------------+---------+-------------+ +------------------+---------+-------------+
| base | 7.16.2 | 0..1 | | base | 7.16.2 | 0..1 |
| 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.6 | 0..n | | pattern | 9.4.5 | 0..n |
| range | 9.2.4 | 0..1 | | range | 9.2.4 | 0..1 |
| require-instance | 9.13.2 | 0..1 | | require-instance | 9.9.3 | 0..1 |
| type | 7.4 | 0..n | | type | 7.4 | 0..n |
+------------------+---------+-------------+ +------------------+---------+-------------+
7.5. The container Statement 7.5. The container Statement
The "container" statement is used to define an interior data node in The "container" statement is used to define an interior data node in
the schema tree. It takes one argument, which is an identifier, the schema tree. It takes one argument, which is an identifier,
followed by a block of substatements that holds detailed container followed by a block of substatements that holds detailed container
information. information.
skipping to change at page 54, line 11 skipping to change at page 54, line 11
all leafs with default values in use (see Section 7.6.1). all leafs with default values in use (see Section 7.6.1).
The accessible tree depends on the context node: The accessible tree depends on the context node:
o If the context node represents configuration, the tree is the data o If the context node represents configuration, the tree is the data
in the NETCONF datastore where the context node exists. The XPath in the NETCONF datastore where the context node exists. The XPath
root node has all top-level configuration data nodes in all root node has all top-level configuration data nodes in all
modules as children. modules as children.
o If the context node represents state data, the tree is all state o If the context node represents state data, the tree is all state
data on the device, and the <running/> datastore. The XPath root data on the device, and the "running" datastore. The XPath root
node has all top-level data nodes in all modules as children. node has all top-level data nodes in all modules as children.
o If the context node represents notification content, the tree is o If the context node represents notification content, the tree is
the notification XML instance document. The XPath root node has the notification XML instance document. The XPath root node has
the element representing the notification being defined as the the element representing the notification being defined as the
only child. only child.
o If the context node represents RPC input parameters, the tree is o If the context node represents RPC input parameters, the tree is
the RPC XML instance document. The XPath root node has the the RPC XML instance document. The XPath root node has the
element representing the RPC operation being defined as the only element representing the RPC operation being defined as the only
skipping to change at page 69, line 6 skipping to change at page 69, line 6
leafs or their types are ignored. It also implies that any mandatory leafs or their types are ignored. It also implies that any mandatory
statement in the key leafs are ignored. statement in the key leafs are ignored.
A leaf that is part of the key can be of any built-in or derived A leaf that is part of the key can be of any built-in or derived
type, except it MUST NOT be the built-in type "empty". type, except it MUST NOT be the built-in type "empty".
All key leafs in a list MUST have the same value for their "config" All key leafs in a list MUST have the same value for their "config"
as the list itself. as the list itself.
The key string syntax is formally defined by the rule "key-arg" in The key string syntax is formally defined by the rule "key-arg" in
Section 12. Section 13.
7.8.3. The list's unique Statement 7.8.3. The list's unique Statement
The "unique" statement is used to put constraints on valid list The "unique" statement is used to put constraints on valid list
entries. It takes as an argument a string that contains a space- entries. It takes as an argument a string that contains a space-
separated list of schema node identifiers, which MUST be given in the separated list of schema node identifiers, which MUST be given in the
descendant form (see the rule "descendant-schema-nodeid" in descendant form (see the rule "descendant-schema-nodeid" in
Section 12). Each such schema node identifier MUST refer to a leaf. Section 13). Each such schema node identifier MUST refer to a leaf.
If one of the referenced leafs represents configuration data, then If one of the referenced leafs represents configuration data, then
all of the referenced leafs MUST represent configuration data. all of the referenced leafs MUST represent configuration data.
The "unique" constraint specifies that the combined values of all the The "unique" constraint specifies that the combined values of all the
leaf instances specified in the argument string, including leafs with leaf instances specified in the argument string, including leafs with
default values, MUST be unique within all list entry instances in default values, MUST be unique within all list entry instances in
which all referenced leafs exist. The constraint is enforced which all referenced leafs exist. The constraint is enforced
according to the rules in Section 8. according to the rules in Section 8.
The unique string syntax is formally defined by the rule "unique-arg" The unique string syntax is formally defined by the rule "unique-arg"
in Section 12. in Section 13.
7.8.3.1. Usage Example 7.8.3.1. Usage Example
With the following list: With the following list:
list server { list server {
key "name"; key "name";
unique "ip port"; unique "ip port";
leaf name { leaf name {
type string; type string;
skipping to change at page 76, line 9 skipping to change at page 76, line 9
time. time.
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 |
| config | 7.19.1 | 0..1 | | config | 7.19.1 | 0..1 |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| default | 7.9.3 | 0..1 | | default | 7.9.3 | 0..1 |
| description | 7.19.3 | 0..1 | | description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n | | if-feature | 7.18.2 | 0..n |
| leaf | 7.6 | 0..n | | leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n | | leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n | | list | 7.8 | 0..n |
| mandatory | 7.9.4 | 0..1 | | mandatory | 7.9.4 | 0..1 |
| reference | 7.19.4 | 0..1 | | reference | 7.19.4 | 0..1 |
skipping to change at page 76, line 48 skipping to change at page 76, line 49
choice interface-type { // This example is illegal YANG choice interface-type { // This example is illegal YANG
case a { case a {
leaf ethernet { ... } leaf ethernet { ... }
} }
case b { case b {
container ethernet { ...} container ethernet { ...}
} }
} }
As a shorthand, the "case" statement can be omitted if the branch As a shorthand, the "case" statement can be omitted if the branch
contains a single "anyxml", "container", "leaf", "list", or contains a single "anyxml", "choice", "container", "leaf", "list", or
"leaf-list" statement. In this case, the identifier of the case node "leaf-list" statement. In this case, the identifier of the case node
is the same as the identifier in the branch statement. The following is the same as the identifier in the branch statement. The following
example: example:
choice interface-type { choice interface-type {
container ethernet { ... } container ethernet { ... }
} }
is equivalent to: is equivalent to:
skipping to change at page 85, line 32 skipping to change at page 85, line 32
statement. statement.
o A container node may get a "presence" statement. o A container node may get a "presence" statement.
o A leaf, leaf-list, list, container, or anyxml node may get o A leaf, leaf-list, list, container, or anyxml node may get
additional "must" expressions. additional "must" expressions.
o A leaf-list or list node may get a different "min-elements" or o A leaf-list or list node may get a different "min-elements" or
"max-elements" statement. "max-elements" statement.
o A leaf, leaf-list, list, container, or anyxml node may get
additional "if-feature" expressions.
7.12.3. XML Mapping Rules 7.12.3. XML Mapping Rules
Each node in the grouping is encoded as if it was defined inline, Each node in the grouping is encoded as if it was defined inline,
even if it is imported from another module with another XML even if it is imported from another module with another XML
namespace. namespace.
7.12.4. Usage Example 7.12.4. Usage Example
To use the "endpoint" grouping defined in Section 7.11.2 in a To use the "endpoint" grouping defined in Section 7.11.2 in a
definition of an HTTP server in some other module, we can do: definition of an HTTP server in some other module, we can do:
skipping to change at page 92, line 33 skipping to change at page 92, line 33
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.
The argument string is a schema node identifier (see Section 6.5). The argument string is a schema node identifier (see Section 6.5).
If the "augment" statement is on the top level in a module or If the "augment" statement is on the top level in a module or
submodule, the absolute form (defined by the rule submodule, the absolute form (defined by the rule
"absolute-schema-nodeid" in Section 12) of a schema node identifier "absolute-schema-nodeid" in Section 13) of a schema node identifier
MUST be used. If the "augment" statement is a substatement to the MUST be used. If the "augment" statement is a substatement to the
"uses" statement, the descendant form (defined by the rule "uses" statement, the descendant form (defined by the rule
"descendant-schema-nodeid" in Section 12) MUST be used. "descendant-schema-nodeid" in Section 13) MUST be used.
If the target node is a container, list, case, input, output, or If the target node is a container, list, case, input, output, or
notification node, the "container", "leaf", "list", "leaf-list", notification node, the "container", "leaf", "list", "leaf-list",
"uses", and "choice" statements can be used within the "augment" "uses", and "choice" statements can be used within the "augment"
statement. statement.
If the target node is a 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.
skipping to change at page 98, line 10 skipping to change at page 98, line 10
The extension can be used like a normal YANG statement, with the The extension can be used like a normal YANG statement, with the
statement name followed by an argument if one is defined by the statement name followed by an argument if one is defined by the
"extension" statement, and an optional block of substatements. The "extension" statement, and an optional block of substatements. The
statement's name is created by combining the prefix of the module in statement's name is created by combining the prefix of the module in
which the extension was defined, a colon (":"), and the extension's which the extension was defined, a colon (":"), and the extension's
keyword, with no interleaving whitespace. The substatements of an keyword, with no interleaving whitespace. The substatements of an
extension are defined by the "extension" statement, using some extension are defined by the "extension" statement, using some
mechanism outside the scope of this specification. Syntactically, mechanism outside the scope of this specification. Syntactically,
the substatements MUST be YANG statements, or also extensions defined the substatements MUST be YANG statements, or also extensions defined
using "extension" statements. YANG statements in extensions MUST using "extension" statements. YANG statements in extensions MUST
follow the syntactical rules in Section 12. follow the syntactical rules in Section 13.
7.17.1. The extension's Substatements 7.17.1. The extension's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| argument | 7.17.2 | 0..1 | | argument | 7.17.2 | 0..1 |
| description | 7.19.3 | 0..1 | | description | 7.19.3 | 0..1 |
| reference | 7.19.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.19.2 | 0..1 |
skipping to change at page 98, line 47 skipping to change at page 98, line 47
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+----------+-------------+ +--------------+----------+-------------+
| yin-element | 7.17.2.2 | 0..1 | | yin-element | 7.17.2.2 | 0..1 |
+--------------+----------+-------------+ +--------------+----------+-------------+
7.17.2.2. The yin-element Statement 7.17.2.2. The yin-element Statement
The "yin-element" statement, which is optional, takes as an argument The "yin-element" statement, which is optional, takes as an argument
the string "true" or "false". This statement indicates if the the string "true" or "false". This statement indicates if the
argument 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 11). (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.17.3. Usage Example
To define an extension: To define an extension:
module my-extensions { module my-extensions {
... ...
skipping to change at page 99, line 46 skipping to change at page 99, line 46
7.18. Conformance-Related Statements 7.18. 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.18.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 a feature are ignored (see Section 7.18.2). Schema nodes tagged with an "if-feature"
by the device unless the device supports the given feature. This statement are ignored by the device unless the device supports the
allows portions of the YANG module to be conditional based on given feature expression. This allows portions of the YANG module to
conditions on the device. The model can represent the abilities of be conditional based on conditions on the device. The model can
the device within the model, giving a richer model that allows for represent the abilities of the device within the model, giving a
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.
In this example, a feature called "local-storage" represents the In this example, a feature called "local-storage" represents the
ability for a device to store syslog messages on local storage of ability for a device to store syslog messages on local storage of
some sort. This feature is used to make the "local-storage-limit" some sort. This feature is used to make the "local-storage-limit"
leaf conditional on the presence of some sort of local storage. If leaf conditional on the presence of some sort of local storage. If
skipping to change at page 101, line 19 skipping to change at page 101, line 19
+--------------+---------+-------------+ +--------------+---------+-------------+
| description | 7.19.3 | 0..1 | | description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n | | if-feature | 7.18.2 | 0..n |
| status | 7.19.2 | 0..1 | | status | 7.19.2 | 0..1 |
| reference | 7.19.4 | 0..1 | | reference | 7.19.4 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.18.2. The if-feature Statement 7.18.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 the name of a feature, as defined by a "feature" The argument is a boolean expression over feature names. In this
statement. The parent statement is implemented by servers that expression, a feature name evaluates to "true" if and only if the
support this feature. If a prefix is present on the feature name, it feature is implemented by the server. The parent statement is
refers to a feature defined in the module that was imported with that implemented by servers where the boolean expression evaluates to
prefix, or the local module if the prefix matches the local module's "true".
prefix. Otherwise, a feature with the matching name MUST be defined
in the current module or an included submodule. The if-feature boolean expression syntax is formally defined by the
rule "if-feature-expr" in Section 13. When this boolean expression
is evaluated, the operator order of precedence is (highest precedence
first): "not", "and", "or".
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
imported with that prefix, or the local module if the prefix matches
the local module's prefix. Otherwise, a feature with the matching
name MUST be defined in the current module or an included submodule.
Since submodules cannot include the parent module, any features in Since submodules cannot include the parent module, any features in
the module that need to be exposed to submodules MUST be defined in a the module that need to be exposed to submodules MUST be defined in a
submodule. Submodules can then include this submodule to find the submodule. Submodules can then include this submodule to find the
definition of the feature. definition of the feature.
A leaf that is a list key MUST NOT have any "if-feature" statements,
unless the conditions specified in the "if-feature" statements are
the same as the "if-feature" conditions in effect on the leaf's
parent node.
7.18.2.1. Usage Example
In this example, the container "target" is implemented if any of the
features "outbound-tls" or "outbound-ssh" is implemented by the
server.
container target {
if-feature "outbound-tls or outbound-ssh";
...
}
7.18.3. The deviation Statement 7.18.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
skipping to change at page 106, line 16 skipping to change at page 106, line 42
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.
A leaf that is a list key MUST NOT have a "when" statement, unless
the condition specified in the "when" statement is the same as the
"when" condition in effect on the leaf's parent node.
See Section 8.3.2 for additional information. See Section 8.3.2 for additional information.
The XPath expression is conceptually evaluated in the following The XPath expression is conceptually evaluated in the following
context, in addition to the definition in Section 6.4.1: context, in addition to the definition in Section 6.4.1:
o If the "when" statement is a child of an "augment" statement, then o If the "when" statement is a child of an "augment" statement, then
the context node is the augment's target node in the data tree, if the context node is the augment's target node in the data tree, if
the target node is a data node. Otherwise, the context node is the target node is a data node. Otherwise, the context node is
the closest ancestor node to the target node that is also a data the closest ancestor node to the target node that is also a data
node. node.
skipping to change at page 106, line 47 skipping to change at page 107, line 28
all leafs with default values in use (see Section 7.6.1). all leafs with default values in use (see Section 7.6.1).
The accessible tree depends on the context node: The accessible tree depends on the context node:
o If the context node represents configuration, the tree is the data o If the context node represents configuration, the tree is the data
in the NETCONF datastore where the context node exists. The XPath in the NETCONF datastore where the context node exists. The XPath
root node has all top-level configuration data nodes in all root node has all top-level configuration data nodes in all
modules as children. modules as children.
o If the context node represents state data, the tree is all state o If the context node represents state data, the tree is all state
data on the device, and the <running/> datastore. The XPath root data on the device, and the "running" datastore. The XPath root
node has all top-level data nodes in all modules as children. node has all top-level data nodes in all modules as children.
o If the context node represents notification content, the tree is o If the context node represents notification content, the tree is
the notification XML instance document. The XPath root node has the notification XML instance document. The XPath root node has
the element representing the notification being defined as the the element representing the notification being defined as the
only child. only child.
o If the context node represents RPC input parameters, the tree is o If the context node represents RPC input parameters, the tree is
the RPC XML instance document. The XPath root node has the the RPC XML instance document. The XPath root node has the
element representing the RPC operation being defined as the only element representing the RPC operation being defined as the only
skipping to change at page 109, line 6 skipping to change at page 109, line 30
app-tag and error-message associated with the constraint, if any app-tag and error-message associated with the constraint, if any
exist. exist.
o If all keys of a list entry are not present, the server MUST reply o If all keys of a list entry are not present, the server MUST reply
with a "missing-element" error-tag in the rpc-error. with a "missing-element" error-tag in the rpc-error.
o If data for more than one case branch of a choice is present, the o If data for more than one case branch of a choice is present, the
server MUST reply with a "bad-element" in the rpc-error. server MUST reply with a "bad-element" in the rpc-error.
o If data for a node tagged with "if-feature" is present, and the o If data for a node tagged with "if-feature" is present, and the
feature is not supported by the device, the server MUST reply with if-feature expression evaluates to "false" on the device, the
an "unknown-element" error-tag in the rpc-error. server MUST reply with an "unknown-element" error-tag in the rpc-
error.
o If data for a node tagged with "when" is present, and the "when" o If data for a node tagged with "when" is present, and the "when"
condition evaluates to "false", the server MUST reply with an condition evaluates to "false", the server MUST reply with an
"unknown-element" error-tag in the rpc-error. "unknown-element" error-tag in the rpc-error.
o For insert handling, if the value for the attributes "before" and o For insert handling, if the value for the attributes "before" and
"after" are not valid for the type of the appropriate key leafs, "after" are not valid for the type of the appropriate key leafs,
the server MUST reply with a "bad-attribute" error-tag in the rpc- the server MUST reply with a "bad-attribute" error-tag in the rpc-
error. error.
skipping to change at page 109, line 51 skipping to change at page 110, line 29
o If the NETCONF operation modifies a data node such that any node's o If the NETCONF operation modifies a data node such that any node's
"when" expression becomes false, then the node with the "when" "when" expression becomes false, then the node with the "when"
expression is deleted by the server. expression is deleted by the server.
8.3.3. Validation 8.3.3. Validation
When datastore processing is complete, the final contents MUST obey When datastore processing is complete, the final contents MUST obey
all validation constraints. This validation processing is performed all validation constraints. This validation processing is performed
at differing times according to the datastore. If the datastore is at differing times according to the datastore. If the datastore is
<running/> or <startup/>, these constraints MUST be enforced at the "running" or "startup", these constraints MUST be enforced at the end
end of the <edit-config> or <copy-config> operation. If the of the <edit-config> or <copy-config> operation. If the datastore is
datastore is <candidate/>, the constraint enforcement is delayed "candidate", the constraint enforcement is delayed until a <commit>
until a <commit> or <validate> operation. or <validate> operation.
o Any "must" constraints MUST evaluate to "true". o Any "must" constraints MUST evaluate to "true".
o Any referential integrity constraints defined via the "path" o Any referential integrity constraints defined via the "path"
statement MUST be satisfied. statement MUST be satisfied.
o Any "unique" constraints on lists MUST be satisfied. o Any "unique" constraints on lists MUST be satisfied.
o The "min-elements" and "max-elements" constraints are enforced for o The "min-elements" and "max-elements" constraints are enforced for
lists and leaf-lists. lists and leaf-lists.
skipping to change at page 110, line 29 skipping to change at page 111, line 11
YANG has a set of built-in types, similar to those of many YANG has a set of built-in types, similar to those of many
programming languages, but with some differences due to special programming languages, but with some differences due to special
requirements from the management information model. requirements from the management information model.
Additional types may be defined, derived from those built-in types or Additional types may be defined, derived from those built-in types or
from other derived types. Derived types may use subtyping to from other derived types. Derived types may use subtyping to
formally restrict the set of possible values. formally restrict the set of possible values.
The different built-in types and their derived types allow different The different built-in types and their derived types allow different
kinds of subtyping, namely length and regular expression restrictions kinds of subtyping, namely length and regular expression restrictions
of strings (Section 9.4.4, Section 9.4.6) and range restrictions of of strings (Section 9.4.4, Section 9.4.5) and range restrictions of
numeric types (Section 9.2.4). numeric types (Section 9.2.4).
The lexical representation of a value of a certain type is used in The lexical representation of a value of a certain type is used in
the NETCONF messages and when specifying default values and numerical the NETCONF messages and when specifying default values and numerical
ranges in YANG modules. ranges in YANG modules.
9.1. Canonical Representation 9.1. Canonical Representation
For most types, there is a single canonical representation of the For most types, there is a single canonical representation of the
type's values. Some types allow multiple lexical representations of type's values. Some types allow multiple lexical representations of
skipping to change at page 112, line 49 skipping to change at page 113, line 32
range-restricted type, the new restriction MUST be equal or more range-restricted type, the new restriction MUST be equal or more
limiting, that is raising the lower bounds, reducing the upper limiting, that is raising the lower bounds, reducing the upper
bounds, removing explicit values or ranges, or splitting ranges into bounds, removing explicit values or ranges, or splitting ranges into
multiple ranges with intermediate gaps. Each explicit value and multiple ranges with intermediate gaps. Each explicit value and
range boundary value given in the range expression MUST match the range boundary value given in the range expression MUST match the
type being restricted, or be one of the special values "min" or type being restricted, or be one of the special values "min" or
"max". "min" and "max" mean the minimum and maximum value accepted "max". "min" and "max" mean the minimum and maximum value accepted
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 12. "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.19.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.19.4 | 0..1 |
skipping to change at page 115, line 39 skipping to change at page 116, line 30
instance documents. instance documents.
9.4.2. Canonical Form 9.4.2. Canonical Form
The canonical form is the same as the lexical representation. No The canonical form is the same as the lexical representation. No
Unicode normalization is performed of string values. Unicode normalization is performed of string values.
9.4.3. Restrictions 9.4.3. Restrictions
A string can be restricted with the "length" (Section 9.4.4) and A string can be restricted with the "length" (Section 9.4.4) and
"pattern" (Section 9.4.6) statements. "pattern" (Section 9.4.5) statements.
9.4.4. The length Statement 9.4.4. The length Statement
The "length" statement, which is an optional substatement to the The "length" statement, which is an optional substatement to the
"type" statement, takes as an argument a length expression string. "type" statement, takes as an argument a length expression string.
It is used to restrict the built-in types "string" and "binary" or It is used to restrict the built-in types "string" and "binary" or
types derived from them. types derived from them.
A "length" statement restricts the number of Unicode characters in A "length" statement restricts the number of Unicode characters in
the string. the string.
skipping to change at page 116, line 18 skipping to change at page 117, line 9
MUST be equal or more limiting, that is, raising the lower bounds, MUST be equal or more limiting, that is, raising the lower bounds,
reducing the upper bounds, removing explicit length values or ranges, reducing the upper bounds, removing explicit length values or ranges,
or splitting ranges into multiple ranges with intermediate gaps. A or splitting ranges into multiple ranges with intermediate gaps. A
length value is a non-negative integer, or one of the special values length value is a non-negative integer, or one of the special values
"min" or "max". "min" and "max" mean the minimum and maximum length "min" or "max". "min" and "max" mean the minimum and maximum length
accepted for the type being restricted, respectively. An accepted for the type being restricted, respectively. An
implementation is not required to support a length value larger than implementation is not required to support a length value larger than
18446744073709551615. 18446744073709551615.
The length expression syntax is formally defined by the rule The length expression syntax is formally defined by the rule
"length-arg" in Section 12. "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.19.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.19.4 | 0..1 |
+---------------+---------+-------------+ +---------------+---------+-------------+
9.4.5. Usage Example 9.4.5. The pattern Statement
typedef my-base-str-type {
type string {
length "1..255";
}
}
type my-base-str-type {
// legal length refinement
length "11 | 42..max"; // 11 | 42..255
}
type my-base-str-type {
// illegal length refinement
length "1..999";
}
9.4.6. The pattern Statement
The "pattern" statement, which is an optional substatement to the The "pattern" statement, which is an optional substatement to the
"type" statement, takes as an argument a regular expression string, "type" statement, takes as an argument a regular expression string,
as defined in [XSD-TYPES]. It is used to restrict the built-in type as defined in [XSD-TYPES]. It is used to restrict the built-in type
"string", or types derived from "string", to values that match the "string", or types derived from "string", to values that match the
pattern. pattern.
If the type has multiple "pattern" statements, the expressions are If the type has multiple "pattern" statements, the expressions are
ANDed together, i.e., all such expressions have to match. ANDed together, i.e., all such expressions have to match.
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.6.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.19.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 |
| reference | 7.19.4 | 0..1 | | reference | 7.19.4 | 0..1 |
+---------------+---------+-------------+ +---------------+---------+-------------+
9.4.6. The modifier Statement
9.4.7. Usage Example 9.4.7. Usage Example
With the following typedef:
typedef my-base-str-type {
type string {
length "1..255";
}
}
the following refinement is legal:
type my-base-str-type {
// legal length refinement
length "11 | 42..max"; // 11 | 42..255
}
and the following refinement is illegal:
type my-base-str-type {
// illegal length refinement
length "1..999";
}
With the following type: With the following type:
type string { type string {
length "0..4"; length "0..4";
pattern "[0-9a-fA-F]*"; pattern "[0-9a-fA-F]*";
} }
the following strings match: the following strings match:
AB // legal AB // legal
9A00 // legal 9A00 // legal
and the following strings do not match: and the following strings do not match:
00ABAB // illegal, too long 00ABAB // illegal, too long
xx00 // illegal, bad characters xx00 // illegal, bad characters
With the following type:
typedef yang-identifier {
type string {
length "1..max";
pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
pattern '[xX][mM][lL].*' {
modifier invert-match;
}
}
}
the following string match:
enabled // legal
and the following strings do not match:
10-mbit // illegal, starts with a number
xml-element // illegal, starts with illegal sequence
9.5. The boolean Built-In Type 9.5. The boolean Built-In Type
The boolean built-in type represents a boolean value. The boolean built-in type represents a boolean value.
9.5.1. Lexical Representation 9.5.1. Lexical Representation
The lexical representation of a boolean value is a string with a The lexical representation of a boolean value is a string with a
value of "true" or "false". These values MUST be in lowercase. value of "true" or "false". These values MUST be in lowercase.
9.5.2. Canonical Form 9.5.2. Canonical Form
skipping to change at page 122, line 33 skipping to change at page 124, line 5
The canonical form of a binary value follows the rules in [RFC4648]. The canonical form of a binary value follows the rules in [RFC4648].
9.9. The leafref Built-In Type 9.9. The leafref Built-In Type
The leafref type is used to declare a constraint on the value space The leafref type is used to declare a constraint on the value space
of a leaf, based on a reference to a set of leaf instances in the of a leaf, based on a reference to a set of leaf instances in the
data tree. The "path" substatement (Section 9.9.2) selects a set of data tree. The "path" substatement (Section 9.9.2) selects a set of
leaf instances, and the leafref value space is the set of values of leaf instances, and the leafref value space is the set of values of
these leaf instances. these leaf instances.
If the leaf with the leafref type represents configuration data, the If the leaf with the leafref type represents configuration data, and
leaf it refers to MUST also represent configuration. Such a leaf the "require-instance" property (Section 9.9.3) is "true", the leaf
puts a constraint on valid data. All leafref nodes MUST reference it refers to MUST also represent configuration. Such a leaf puts a
existing leaf instances or leafs with default values in use (see constraint on valid data. All such nodes MUST reference existing
leaf instances or leafs with default values in use (see
Section 7.6.1) for the data to be valid. This constraint is enforced Section 7.6.1) for the data to be valid. This constraint is enforced
according to the rules in Section 8. 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.18.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 cannot be restricted. A leafref can be restricted with the "require-instance" statement
(Section 9.9.3).
9.9.2. The path Statement 9.9.2. The path Statement
The "path" statement, which is a substatement to the "type" The "path" statement, which is a substatement to the "type"
statement, MUST be present if the type is "leafref". It takes as an statement, MUST be present if the type is "leafref". It takes as an
argument a string that MUST refer to a leaf or leaf-list node. argument a string that MUST refer to a leaf or leaf-list node.
The syntax for a path argument is a subset of the XPath abbreviated The syntax for a path argument is a subset of the XPath abbreviated
syntax. Predicates are used only for constraining the values for the syntax. Predicates are used only for constraining the values for the
key nodes for list entries. Each predicate consists of exactly one key nodes for list entries. Each predicate consists of exactly one
equality test per key, and multiple adjacent predicates MAY be equality test per key, and multiple adjacent predicates MAY be
present if a list has multiple keys. The syntax is formally defined present if a list has multiple keys. The syntax is formally defined
by the rule "path-arg" in Section 12. by the rule "path-arg" in Section 13.
The predicates are only used when more than one key reference is The predicates are only used when more than one key reference is
needed to uniquely identify a leaf instance. This occurs if a list needed to uniquely identify a leaf instance. This occurs if a list
has multiple keys, or a reference to a leaf other than the key in a has multiple keys, or a reference to a leaf other than the key in a
list is needed. In these cases, multiple leafrefs are typically list is needed. In these cases, multiple leafrefs are typically
specified, and predicates are used to tie them together. specified, and predicates are used to tie them together.
The "path" expression evaluates to a node set consisting of zero, The "path" expression evaluates to a node set consisting of zero,
one, or more nodes. If the leaf with the leafref type represents one, or more nodes. If the leaf with the leafref type represents
configuration data, this node set MUST be non-empty. configuration data, this node set MUST be non-empty.
skipping to change at page 123, line 42 skipping to change at page 125, line 13
statement is defined. statement is defined.
The accessible tree depends on the context node: The accessible tree depends on the context node:
o If the context node represents configuration data, the tree is the o If the context node represents configuration data, the tree is the
data in the NETCONF datastore where the context node exists. The data in the NETCONF datastore where the context node exists. The
XPath root node has all top-level configuration data nodes in all XPath root node has all top-level configuration data nodes in all
modules as children. modules as children.
o Otherwise, the tree is all state data on the device, and the o Otherwise, the tree is all state data on the device, and the
<running/> datastore. The XPath root node has all top-level data "running" datastore. The XPath root node has all top-level data
nodes in all modules as children. nodes in all modules as children.
9.9.3. Lexical Representation 9.9.3. The require-instance Statement
The "require-instance" statement, which is a substatement to the
"type" statement, MAY be present if the type is "instance-identifier"
or "leafref". It takes as an argument the string "true" or "false".
If this statement is not present, it defaults to "true".
If "require-instance" is "true", it means that the instance being
referred MUST exist for the data to be valid. This constraint is
enforced according to the rules in Section 8.
If "require-instance" is "false", it means that the instance being
referred MAY exist in valid data.
9.9.4. Lexical Representation
A leafref value is encoded the same way as the leaf it references. A leafref value is encoded the same way as the leaf it references.
9.9.4. Canonical Form 9.9.5. Canonical Form
The canonical form of a leafref is the same as the canonical form of The canonical form of a leafref is the same as the canonical form of
the leaf it references. the leaf it references.
9.9.5. Usage Example 9.9.6. Usage Example
With the following list: With the following list:
list interface { list interface {
key "name"; key "name";
leaf name { leaf name {
type string; type string;
} }
leaf admin-status { leaf admin-status {
type admin-status; type admin-status;
skipping to change at page 128, line 21 skipping to change at page 130, line 21
namespace of the identityref is the default namespace in effect on namespace of the identityref is the default namespace in effect on
the element that contains the identityref value. the element that contains the identityref value.
When an identityref is given a default value using the "default" When an identityref is given a default value using the "default"
statement, the identity name in the default value MAY have a prefix. statement, the identity name in the default value MAY have a prefix.
If a prefix is present on the identity name, it refers to an identity If a prefix is present on the identity name, it refers to an identity
defined in the module that was imported with that prefix. Otherwise, defined in the module that was imported with that prefix. Otherwise,
an identity with the matching name MUST be defined in the current an identity with the matching name MUST be defined in the current
module or an included submodule. module or an included submodule.
The string value of a node of type identityref in a "must" or "when"
XPath expression is the referred identity's qualified name with the
prefix always present.
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.16.3 and the following
module: module:
skipping to change at page 128, line 49 skipping to change at page 131, line 23
identity aes { identity aes {
base "crypto:crypto-alg"; base "crypto:crypto-alg";
} }
leaf crypto { leaf crypto {
type identityref { type identityref {
base "crypto:crypto-alg"; base "crypto:crypto-alg";
} }
} }
container aes-parameters {
when "../crypto = 'mc:aes';
...
}
} }
the following is an example how the leaf "crypto" can be encoded, if the following is an example how the leaf "crypto" can be encoded, if
the value is the "des3" identity defined in the "des" module: the value is the "des3" identity defined in the "des" module:
<crypto xmlns:des="http://example.com/des">des:des3</crypto> <crypto xmlns:des="http://example.com/des">des:des3</crypto>
Any prefixes used in the encoding are local to each instance Any prefixes used in the encoding are local to each instance
encoding. This means that the same identityref may be encoded encoding. This means that the same identityref may be encoded
differently by different implementations. For example, the following differently by different implementations. For example, the following
skipping to change at page 130, line 21 skipping to change at page 132, line 48
9.12. The union Built-In Type 9.12. The union Built-In Type
The union built-in type represents a value that corresponds to one of The union built-in type represents a value that corresponds to one of
its member types. its member types.
When the type is "union", the "type" statement (Section 7.4) MUST be When the type is "union", the "type" statement (Section 7.4) MUST be
present. It is used to repeatedly specify each member type of the present. It is used to repeatedly specify each member type of the
union. It takes as an argument a string that is the name of a member union. It takes as an argument a string that is the name of a member
type. type.
A member type can be of any built-in or derived type, except it MUST A member type can be of any built-in or derived type.
NOT be one of the built-in types "empty" or "leafref".
When a string representing a union data type is validated, the string When a string representing a union data type is validated, the string
is validated against each member type, in the order they are is validated against each member type, in the order they are
specified in the "type" statement, until a match is found. specified in the "type" statement, until a match is found. The type
that matched will be the type of the value for the node that was
validated.
Any default value or "units" property defined in the member types is Any default value or "units" property defined in the member types is
not inherited by the union type. not inherited by the union type.
Example:
type union {
type int32;
type enumeration {
enum "unbounded";
}
}
9.12.1. Restrictions 9.12.1. Restrictions
A union cannot be restricted. However, each member type can be A union cannot be restricted. However, each member type can be
restricted, based on the rules defined in Section 9. restricted, based on the rules defined in Section 9.
9.12.2. Lexical Representation 9.12.2. Lexical Representation
The lexical representation of a union is a value that corresponds to The lexical representation of a union is a value that corresponds to
the representation of any one of the member types. the representation of any one of the member types.
9.12.3. Canonical Form 9.12.3. Canonical Form
The canonical form of a union value is the same as the canonical form The canonical form of a union value is the same as the canonical form
of the member type of the value. of the member type of the value.
9.12.4. Usage Example
The following is a union of an int32 an enumeration:
type union {
type int32;
type enumeration {
enum "unbounded";
}
}
Care must be taken when a member type is a leafref where the
"require-instance" property (Section 9.9.3) is "true". If a leaf of
such a type refers to an existing instance, the leaf's value must be
re-validated if the target instance is deleted. For example, with
the following definitions:
list filter {
key name;
leaf name {
type string;
}
...
}
leaf outbound-filter {
type union {
type leafref {
path "/filter/name";
}
type enumeration {
enum default-filter;
}
}
}
assume that there exists an entry in the filter list with the name
"http", and that the outbound-filter leaf has this value:
<filter>
<name>http</name>
</filter>
<outbound-filter>http</outbound-filter>
If the filter entry "http" is removed, the outbound-filter leaf's
value doesn't match the leafref, and the next member type is checked.
The current value ("http") doesn't match the enumeration, so the
resulting configuration is invalid.
If the second member type in the union had been of type "string"
instead of an enumeration, the current value would have matched, and
the resulting configuration would have been valid.
9.13. The instance-identifier Built-In Type 9.13. The instance-identifier Built-In Type
The instance-identifier built-in type is used to uniquely identify a The instance-identifier built-in type is used to uniquely identify a
particular instance node in the data tree. particular instance node in the data tree.
The syntax for an instance-identifier is a subset of the XPath The syntax for an instance-identifier is a subset of the XPath
abbreviated syntax, formally defined by the rule abbreviated syntax, formally defined by the rule
"instance-identifier" in Section 12. It is used to uniquely identify "instance-identifier" in Section 13. It is used to uniquely identify
a node in the data tree. Predicates are used only for specifying the a node in the data tree. Predicates are used only for specifying the
values for the key nodes for list entries, a value of a leaf-list values for the key nodes for list entries, a value of a leaf-list
entry, or a positional index for a list without keys. For entry, or a positional index for a list without keys. For
identifying list entries with keys, each predicate consists of one identifying list entries with keys, each predicate consists of one
equality test per key, and each key MUST have a corresponding equality test per key, and each key MUST have a corresponding
predicate. predicate.
If the leaf with the instance-identifier type represents If the leaf with the instance-identifier type represents
configuration data, and the "require-instance" property configuration data, and the "require-instance" property
(Section 9.13.2) is "true", the node it refers to MUST also represent (Section 9.9.3) is "true", the node it refers to MUST also represent
configuration. Such a leaf puts a constraint on valid data. All configuration. Such a leaf puts a constraint on valid data. All
such leaf nodes MUST reference existing nodes or leaf nodes with such leaf nodes MUST reference existing nodes or leaf nodes with
their default value in use (see Section 7.6.1) for the data to be their default value in use (see Section 7.6.1) for the data to be
valid. This constraint is enforced according to the rules in valid. This constraint is enforced according to the rules in
Section 8. Section 8.
The "instance-identifier" XPath expression is conceptually evaluated The "instance-identifier" XPath expression is conceptually evaluated
in the following context, in addition to the definition in in the following context, in addition to the definition in
Section 6.4.1: Section 6.4.1:
skipping to change at page 131, line 49 skipping to change at page 135, line 31
The accessible tree depends on the leaf with the instance-identifier The accessible tree depends on the leaf with the instance-identifier
type: type:
o If this leaf represents configuration data, the tree is the data o If this leaf represents configuration data, the tree is the data
in the NETCONF datastore where the leaf exists. The XPath root in the NETCONF datastore where the leaf exists. The XPath root
node has all top-level configuration data nodes in all modules as node has all top-level configuration data nodes in all modules as
children. children.
o Otherwise, the tree is all state data on the device, and the o Otherwise, the tree is all state data on the device, and the
<running/> datastore. The XPath root node has all top-level data "running" datastore. The XPath root node has all top-level data
nodes in all modules as children. nodes in all modules as children.
9.13.1. Restrictions 9.13.1. Restrictions
An instance-identifier can be restricted with the "require-instance" An instance-identifier can be restricted with the "require-instance"
statement (Section 9.13.2). statement (Section 9.9.3).
9.13.2. The require-instance Statement
The "require-instance" statement, which is a substatement to the
"type" statement, MAY be present if the type is
"instance-identifier". It takes as an argument the string "true" or
"false". If this statement is not present, it defaults to "true".
If "require-instance" is "true", it means that the instance being
referred MUST exist for the data to be valid. This constraint is
enforced according to the rules in Section 8.
If "require-instance" is "false", it means that the instance being
referred MAY exist in valid data.
9.13.3. Lexical Representation 9.13.2. Lexical Representation
An instance-identifier value is lexically represented as a string. An instance-identifier value is lexically represented as a string.
All node names in an instance-identifier value MUST be qualified with All node names in an instance-identifier value MUST be qualified with
explicit namespace prefixes, and these prefixes MUST be declared in explicit namespace prefixes, and these prefixes MUST be declared in
the XML namespace scope in the instance-identifier's XML element. the XML namespace scope in the instance-identifier's XML element.
Any prefixes used in the encoding are local to each instance Any prefixes used in the encoding are local to each instance
encoding. This means that the same instance-identifier may be encoding. This means that the same instance-identifier may be
encoded differently by different implementations. encoded differently by different implementations.
9.13.4. Canonical Form 9.13.3. 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.13.5. Usage Example 9.13.4. Usage Example
The following are examples of instance identifiers: The following are examples of instance identifiers:
/* instance-identifier for a container */ /* instance-identifier for a container */
/ex:system/ex:services/ex:ssh /ex:system/ex:services/ex:ssh
/* instance-identifier for a leaf */ /* instance-identifier for a leaf */
/ex:system/ex:services/ex:ssh/ex:port /ex:system/ex:services/ex:ssh/ex:port
/* instance-identifier for a list entry */ /* instance-identifier for a list entry */
skipping to change at page 133, line 26 skipping to change at page 136, line 35
/* instance-identifier for a list entry with two keys */ /* instance-identifier for a list entry with two keys */
/ex:system/ex:server[ex:ip='192.0.2.1'][ex:port='80'] /ex:system/ex:server[ex:ip='192.0.2.1'][ex:port='80']
/* instance-identifier for a leaf-list entry */ /* instance-identifier for a leaf-list entry */
/ex:system/ex:services/ex:ssh/ex:cipher[.='blowfish-cbc'] /ex:system/ex:services/ex:ssh/ex:cipher[.='blowfish-cbc']
/* instance-identifier for a list entry without keys */ /* instance-identifier for a list entry without keys */
/ex:stats/ex:port[3] /ex:stats/ex:port[3]
10. Updating a Module 10. XPath Functions
This document defines two generic XPath functions and four YANG type-
specific XPath functions.
10.1. Functions for Node Sets
10.1.1. current()
node-set current()
The function current() takes no input parameters, and returns a node
set with the initial context node.
10.2. Functions for Strings
10.2.1. re-match()
boolean re-match(string subject, string pattern)
The re-match() function returns true if the "subject" string matches
the regular expression "pattern"; otherwise it returns false.
The function "re-match" checks if a string matches a given regular
expression. The regular expressions used are the XML Schema regular
expressions [XSD-TYPES]. Note that this includes implicit anchoring
of the regular expression at the head and tail.
10.2.1.1. Usage Example
The expression:
re-match('1.22.333', '\d{1,3}\.\d{1,3}\.\d{1,3}')
returns true.
To count all logical interfaces called eth0.<number>, do:
count(/interface[re-match(name, 'eth0\.\d+')])
10.3. Functions for the YANG Types "leafref" and "instance-identifier"
10.3.1. deref()
node-set deref(node-set nodes)
The deref() function follows the reference defined by the first node
in document order in the argument "nodes", and returns the nodes it
refers to.
If the first argument node is of type instance-identifier, the
function returns a node set that contains the single node that the
instance identifier refers to, if it exists. If no such node exists,
an empty node-set is returned.
If the first argument node is of type leafref, the function returns a
node set that contains the nodes that the leafref refers to.
If the first argument node is of any other type, an empty node set is
returned.
10.3.1.1. Usage Example
list interface {
key name;
leaf name { ... }
leaf enabled {
type boolean;
}
...
}
leaf mgmt-interface {
type leafref {
path "/interface/name";
}
must 'deref(.)/../enabled = "true"' {
error-message
"The management interface cannot be disabled.";
}
}
10.4. Functions for the YANG Type "identityref"
10.4.1. derived-from()
boolean derived-from(node-set nodes,
string module-name,
string identity-name)
The derived-from() function returns true if the first node in
document order in the argument "nodes" is a node of type identityref,
and its value is an identity that is derived from the identity
"identity-name" defined in the YANG module "module-name"; otherwise
it returns false.
10.4.1.1. Usage Example
module example-interface {
...
identity interface-type;
identity ethernet {
base interface-type;
}
identity fast-ethernet {
base ethernet;
}
identity gigabit-ethernet {
base ethernet;
}
list interface {
key name;
...
leaf type {
type identityref {
base interface-type;
}
}
...
}
augment "/interface" {
when 'derived-from(type,
"example-interface",
"ethernet")';
// ethernet-specific definitions here
}
}
10.5. Functions for the YANG Type "enumeration"
10.5.1. enum-value()
number enum-value(node-set nodes)
The enum-value() function checks if the first node in document order
in the argument "nodes" is a node of type enumeration, and returns
the enum's integer value. If the "nodes" node set is empty, or if
the first node in "nodes" is not of type enumeration, it returns NaN.
10.5.1.1. Usage Example
With this data model:
list alarm {
...
leaf severity {
type enumeration {
enum cleared {
value 1;
}
enum indeterminate {
value 2;
}
enum minor {
value 3;
}
enum warning {
value 4;
}
enum major {
value 5;
}
enum critical {
value 6;
}
}
}
}
the following XPath expression selects only alarms that are of
severity "major" or higher:
/alarm[enum-value(severity) >= 5]
10.6. Functions for the YANG Type "bits"
10.6.1. bit-is-set()
boolean bit-is-set(node-set nodes, string bit-name)
The bit-is-set() function returns true if the first node in document
order in the argument "nodes" is a node of type bits, and its value
has the bit "'bit-name" set; otherwise it returns false.
10.6.1.1. Usage Example
If an interface has this leaf:
leaf flags {
type bits {
bit UP;
bit PROMISCUOUS
bit DISABLED;
}
}
the following XPath expression can be used to select all interfaces
with the UP flag set:
/interface[bit-is-set(flags, "UP")]
11. Updating a Module
As experience is gained with a module, it may be desirable to revise As experience is gained with a module, it may be desirable to revise
that module. However, changes are not allowed if they have any that module. However, changes are not allowed if they have any
potential to cause interoperability problems between a client using potential to cause interoperability problems between a client using
an original specification and a server using an updated an original specification and a server using an updated
specification. specification.
For any published change, a new "revision" statement (Section 7.1.9) For any published change, a new "revision" statement (Section 7.1.9)
MUST be included in front of the existing "revision" statements. If MUST be included in front of the existing "revision" statements. If
there are no existing "revision" statements, then one MUST be added there are no existing "revision" statements, then one MUST be added
skipping to change at page 135, line 35 skipping to change at page 143, line 32
Otherwise, if the semantics of any previous definition are changed Otherwise, if the semantics of any previous definition are changed
(i.e., if a non-editorial change is made to any definition other than (i.e., if a non-editorial change is made to any definition other than
those specifically allowed above), then this MUST be achieved by a those specifically allowed above), then this MUST be achieved by a
new definition with a new identifier. new definition with a new identifier.
In statements that have any data definition statements as In statements that have any data definition statements as
substatements, those data definition substatements MUST NOT be substatements, those data definition substatements MUST NOT be
reordered. reordered.
11. YIN 12. YIN
A YANG module can be translated into an alternative XML-based syntax A YANG module can be translated into an alternative XML-based syntax
called YIN. The translated module is called a YIN module. This called YIN. The translated module is called a YIN module. This
section describes symmetric mapping rules between the two formats. section describes symmetric mapping rules between the two formats.
The YANG and YIN formats contain equivalent information using The YANG and YIN formats contain equivalent information using
different notations. The YIN notation enables developers to different notations. The YIN notation enables developers to
represent YANG data models in XML and therefore use the rich set of represent YANG data models in XML and therefore use the rich set of
XML-based tools for data filtering and validation, automated XML-based tools for data filtering and validation, automated
generation of code and documentation, and other tasks. Tools like generation of code and documentation, and other tasks. Tools like
XSLT or XML validators can be utilized. XSLT or XML validators can be utilized.
The mapping between YANG and YIN does not modify the information The mapping between YANG and YIN does not modify the information
content of the model. Comments and whitespace are not preserved. content of the model. Comments and whitespace are not preserved.
11.1. Formal YIN Definition 12.1. Formal YIN Definition
There is a one-to-one correspondence between YANG keywords and YIN There is a one-to-one correspondence between YANG keywords and YIN
elements. The local name of a YIN element is identical to the elements. The local name of a YIN element is identical to the
corresponding YANG keyword. This means, in particular, that the corresponding YANG keyword. This means, in particular, that the
document element (root) of a YIN document is always <module> or document element (root) of a YIN document is always <module> or
<submodule>. <submodule>.
YIN elements corresponding to the YANG keywords belong to the YIN elements corresponding to the YANG keywords belong to the
namespace whose associated URI is namespace whose associated URI is
"urn:ietf:params:xml:ns:yang:yin:1". "urn:ietf:params:xml:ns:yang:yin:1".
skipping to change at page 138, line 21 skipping to change at page 146, line 16
| units | name | false | | units | name | false |
| uses | name | false | | uses | name | false |
| value | value | false | | value | value | false |
| when | condition | false | | when | condition | false |
| yang-version | value | false | | yang-version | value | false |
| yin-element | value | false | | yin-element | value | false |
+------------------+---------------+-------------+ +------------------+---------------+-------------+
Table 1: Mapping of arguments of the YANG statements. Table 1: Mapping of arguments of the YANG statements.
11.1.1. Usage Example 12.1.1. Usage Example
The following YANG module: The following YANG module:
module acme-foo { module acme-foo {
yang-version 1.1; yang-version 1.1;
namespace "http://acme.example.com/foo"; namespace "http://acme.example.com/foo";
prefix "acfoo"; prefix "acfoo";
import my-extensions { import my-extensions {
prefix "myext"; prefix "myext";
skipping to change at page 139, line 32 skipping to change at page 147, line 32
<leaf name="mtu"> <leaf name="mtu">
<type name="uint32"/> <type name="uint32"/>
<description> <description>
<text>The MTU of the interface.</text> <text>The MTU of the interface.</text>
</description> </description>
<myext:c-define name="MY_MTU"/> <myext:c-define name="MY_MTU"/>
</leaf> </leaf>
</list> </list>
</module> </module>
12. YANG ABNF Grammar 13. YANG ABNF Grammar
In YANG, almost all statements are unordered. The ABNF grammar In YANG, almost all statements are unordered. The ABNF grammar
[RFC5234] defines the canonical order. To improve module [RFC5234] defines the canonical order. To improve module
readability, it is RECOMMENDED that clauses be entered in this order. readability, it is RECOMMENDED that clauses be entered in this order.
Within the ABNF grammar, unordered statements are marked with Within the ABNF grammar, unordered statements are marked with
comments. comments.
This grammar assumes that the scanner replaces YANG comments with a This grammar assumes that the scanner replaces YANG comments with a
single space character. single space character.
skipping to change at page 143, line 20 skipping to change at page 151, line 20
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 stmtsep)
[status-stmt stmtsep] [status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
"}") "}")
if-feature-stmt = if-feature-keyword sep identifier-ref-arg-str if-feature-stmt = if-feature-keyword sep if-feature-expr-str
optsep stmtend optsep stmtend
if-feature-expr-str = < a string that matches the rule
if-feature-expr >
if-feature-expr = '(' if-fature-expr ')' /
if-feature-expr sep boolean-operator sep
if-feature-expr /
'not' sep if-feature-expr /
identifier-ref-arg
boolean-operator = 'and' / 'or'
typedef-stmt = typedef-keyword sep identifier-arg-str optsep typedef-stmt = typedef-keyword sep identifier-arg-str optsep
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
type-stmt stmtsep type-stmt stmtsep
[units-stmt stmtsep] [units-stmt stmtsep]
[default-stmt stmtsep] [default-stmt stmtsep]
[status-stmt stmtsep] [status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
"}" "}"
skipping to change at page 144, line 46 skipping to change at page 153, line 9
[error-message-stmt stmtsep] [error-message-stmt stmtsep]
[error-app-tag-stmt stmtsep] [error-app-tag-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
"}") "}")
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]
[error-message-stmt stmtsep] [error-message-stmt stmtsep]
[error-app-tag-stmt stmtsep] [error-app-tag-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
"}") "}")
modifier-stmt = modifier-keyword sep modifier-arg-str stmtend
modifier-arg-str = < a string that matches the rule
modifier-arg >
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 stmtsep)
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
[value-stmt stmtsep] [value-stmt stmtsep]
[status-stmt stmtsep] [status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
"}") "}")
leafref-specification = path-stmt stmtsep leafref-specification =
;; these stmts can appear in any order
path-stmt stmtsep
[require-instance-stmt stmtsep]
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
skipping to change at page 149, line 52 skipping to change at page 158, line 25
*(if-feature-stmt stmtsep) *(if-feature-stmt stmtsep)
[default-stmt stmtsep] [default-stmt stmtsep]
[config-stmt stmtsep] [config-stmt stmtsep]
[mandatory-stmt stmtsep] [mandatory-stmt stmtsep]
[status-stmt stmtsep] [status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
*((short-case-stmt / case-stmt) stmtsep) *((short-case-stmt / case-stmt) stmtsep)
"}") "}")
short-case-stmt = container-stmt / short-case-stmt = choice-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 stmtsep]
skipping to change at page 150, line 51 skipping to change at page 159, line 27
[status-stmt stmtsep] [status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
*(refine-stmt stmtsep) *(refine-stmt stmtsep)
*(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)
*(must-stmt stmtsep) *(must-stmt stmtsep)
[presence-stmt stmtsep] [presence-stmt stmtsep]
[default-stmt stmtsep] [default-stmt stmtsep]
[config-stmt stmtsep] [config-stmt stmtsep]
[mandatory-stmt stmtsep] [mandatory-stmt stmtsep]
[min-elements-stmt stmtsep] [min-elements-stmt stmtsep]
[max-elements-stmt stmtsep] [max-elements-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
"}" "}"
skipping to change at page 158, line 37 skipping to change at page 167, line 12
include-keyword = 'include' include-keyword = 'include'
input-keyword = 'input' input-keyword = 'input'
key-keyword = 'key' key-keyword = 'key'
leaf-keyword = 'leaf' leaf-keyword = 'leaf'
leaf-list-keyword = 'leaf-list' leaf-list-keyword = 'leaf-list'
length-keyword = 'length' length-keyword = 'length'
list-keyword = 'list' list-keyword = 'list'
mandatory-keyword = 'mandatory' mandatory-keyword = 'mandatory'
max-elements-keyword = 'max-elements' max-elements-keyword = 'max-elements'
min-elements-keyword = 'min-elements' min-elements-keyword = 'min-elements'
modifier-keyword = 'modifier'
module-keyword = 'module' module-keyword = 'module'
must-keyword = 'must' must-keyword = 'must'
namespace-keyword = 'namespace' namespace-keyword = 'namespace'
notification-keyword= 'notification' notification-keyword= 'notification'
ordered-by-keyword = 'ordered-by' ordered-by-keyword = 'ordered-by'
organization-keyword= 'organization' organization-keyword= 'organization'
output-keyword = 'output' output-keyword = 'output'
path-keyword = 'path' path-keyword = 'path'
pattern-keyword = 'pattern' pattern-keyword = 'pattern'
position-keyword = 'position' position-keyword = 'position'
skipping to change at page 159, line 27 skipping to change at page 167, line 51
yang-version-keyword= 'yang-version' yang-version-keyword= 'yang-version'
yin-element-keyword = 'yin-element' yin-element-keyword = 'yin-element'
;; other keywords ;; other keywords
add-keyword = 'add' add-keyword = 'add'
current-keyword = 'current' current-keyword = 'current'
delete-keyword = 'delete' delete-keyword = 'delete'
deprecated-keyword = 'deprecated' deprecated-keyword = 'deprecated'
false-keyword = 'false' false-keyword = 'false'
invert-match-keyword = 'invert-match'
max-keyword = 'max' max-keyword = 'max'
min-keyword = 'min' min-keyword = 'min'
not-supported-keyword = 'not-supported' not-supported-keyword = 'not-supported'
obsolete-keyword = 'obsolete' obsolete-keyword = 'obsolete'
replace-keyword = 'replace' replace-keyword = 'replace'
system-keyword = 'system' system-keyword = 'system'
true-keyword = 'true' true-keyword = 'true'
unbounded-keyword = 'unbounded' unbounded-keyword = 'unbounded'
user-keyword = 'user' user-keyword = 'user'
skipping to change at page 161, line 35 skipping to change at page 170, line 13
; space ; space
VCHAR = %x21-7E VCHAR = %x21-7E
; visible (printing) characters ; visible (printing) characters
WSP = SP / HTAB WSP = SP / HTAB
; whitespace ; whitespace
<CODE ENDS> <CODE ENDS>
13. Error Responses for YANG Related Errors 14. Error Responses for YANG Related Errors
A number of NETCONF error responses are defined for error cases A number of NETCONF error responses are defined for error cases
related to the data-model handling. If the relevant YANG statement related to the data-model handling. If the relevant YANG statement
has an "error-app-tag" substatement, that overrides the default value has an "error-app-tag" substatement, that overrides the default value
specified below. specified below.
13.1. Error Message for Data That Violates a unique Statement 14.1. Error Message for Data That Violates a unique Statement
If a NETCONF operation would result in configuration data where a If a NETCONF operation would result in configuration data where a
unique constraint is invalidated, the following error is returned: unique constraint is invalidated, the following error is returned:
error-tag: operation-failed error-tag: operation-failed
error-app-tag: data-not-unique error-app-tag: data-not-unique
error-info: <non-unique>: Contains an instance identifier that error-info: <non-unique>: Contains an instance identifier that
points to a leaf that invalidates the unique points to a leaf that invalidates the unique
constraint. This element is present once for each constraint. This element is present once for each
non-unique leaf. non-unique leaf.
The <non-unique> element is in the YANG The <non-unique> element is in the YANG
namespace ("urn:ietf:params:xml:ns:yang:1"). namespace ("urn:ietf:params:xml:ns:yang:1").
13.2. Error Message for Data That Violates a max-elements Statement 14.2. Error Message for Data That Violates a max-elements Statement
If a NETCONF operation would result in configuration data where a If a NETCONF operation would result in configuration data where a
list or a leaf-list would have too many entries the following error list or a leaf-list would have too many entries the following error
is returned: is returned:
error-tag: operation-failed error-tag: operation-failed
error-app-tag: too-many-elements error-app-tag: too-many-elements
This error is returned once, with the error-path identifying the list This error is returned once, with the error-path identifying the list
node, even if there are more than one extra child present. node, even if there are more than one extra child present.
13.3. Error Message for Data That Violates a min-elements Statement 14.3. Error Message for Data That Violates a min-elements Statement
If a NETCONF operation would result in configuration data where a If a NETCONF operation would result in configuration data where a
list or a leaf-list would have too few entries the following error is list or a leaf-list would have too few entries the following error is
returned: returned:
error-tag: operation-failed error-tag: operation-failed
error-app-tag: too-few-elements error-app-tag: too-few-elements
This error is returned once, with the error-path identifying the list This error is returned once, with the error-path identifying the list
node, even if there are more than one child missing. node, even if there are more than one child missing.
13.4. Error Message for Data That Violates a must Statement 14.4. Error Message for Data That Violates a must Statement
If a NETCONF operation would result in configuration data where the If a NETCONF operation would result in configuration data where the
restrictions imposed by a "must" statement is violated the following restrictions imposed by a "must" statement is violated the following
error is returned, unless a specific "error-app-tag" substatement is error is returned, unless a specific "error-app-tag" substatement is
present for the "must" statement. present for the "must" statement.
error-tag: operation-failed error-tag: operation-failed
error-app-tag: must-violation error-app-tag: must-violation
13.5. Error Message for Data That Violates a require-instance Statement 14.5. Error Message for Data That Violates a require-instance Statement
If a NETCONF operation would result in configuration data where a If a NETCONF operation would result in configuration data where a
leaf of type "instance-identifier" marked with require-instance leaf of type "instance-identifier" marked with require-instance
"true" refers to a non-existing instance, the following error is "true" refers to a non-existing instance, the following error is
returned: returned:
error-tag: data-missing error-tag: data-missing
error-app-tag: instance-required error-app-tag: instance-required
error-path: Path to the instance-identifier leaf. error-path: Path to the instance-identifier leaf.
13.6. Error Message for Data That Does Not Match a leafref Type 14.6. Error Message for Data That Does Not Match a leafref Type
If a NETCONF operation would result in configuration data where a If a NETCONF operation would result in configuration data where a
leaf of type "leafref" refers to a non-existing instance, the leaf of type "leafref" refers to a non-existing instance, the
following error is returned: following error is returned:
error-tag: data-missing error-tag: data-missing
error-app-tag: instance-required error-app-tag: instance-required
error-path: Path to the leafref leaf. error-path: Path to the leafref leaf.
13.7. Error Message for Data That Violates a mandatory choice Statement 14.7. Error Message for Data That Violates a mandatory choice Statement
If a NETCONF operation would result in configuration data where no If a NETCONF operation would result in configuration data where no
nodes exists in a mandatory choice, the following error is returned: nodes exists in a mandatory choice, the following error is returned:
error-tag: data-missing error-tag: data-missing
error-app-tag: missing-choice error-app-tag: missing-choice
error-path: Path to the element with the missing choice. error-path: Path to the element with the missing choice.
error-info: <missing-choice>: Contains the name of the missing error-info: <missing-choice>: Contains the name of the missing
mandatory choice. mandatory choice.
The <missing-choice> element is in the YANG The <missing-choice> element is in the YANG
namespace ("urn:ietf:params:xml:ns:yang:1"). namespace ("urn:ietf:params:xml:ns:yang:1").
13.8. Error Message for the "insert" Operation 14.8. Error Message for the "insert" Operation
If the "insert" and "key" or "value" attributes are used in an If the "insert" and "key" or "value" attributes are used in an
<edit-config> for a list or leaf-list node, and the "key" or "value" <edit-config> for a list or leaf-list node, and the "key" or "value"
refers to a non-existing instance, the following error is returned: refers to a non-existing instance, the following error is returned:
error-tag: bad-attribute error-tag: bad-attribute
error-app-tag: missing-instance error-app-tag: missing-instance
14. IANA Considerations 15. IANA Considerations
This document defines a registry for YANG module and submodule names. This document defines a registry for YANG module and submodule names.
The name of the registry is "YANG Module Names". The name of the registry is "YANG Module Names".
The registry shall record for each entry: The registry shall record for each entry:
o the name of the module or submodule o the name of the module or submodule
o for modules, the assigned XML namespace o for modules, the assigned XML namespace
skipping to change at page 165, line 5 skipping to change at page 173, line 23
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 two new media types as defined in the This document registers two new media types as defined in the
following sections. following sections.
14.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
Optional parameters: none Optional parameters: none
Encoding considerations: 8-bit Encoding considerations: 8-bit
skipping to change at page 165, line 48 skipping to change at page 174, line 45
Intended usage: COMMON Intended usage: COMMON
Author: Author:
This specification is a work item of the IETF NETMOD working This specification is a work item of the IETF NETMOD working
group, with mailing list address <netmod@ietf.org>. group, with mailing list address <netmod@ietf.org>.
Change controller: Change controller:
The IESG <iesg@ietf.org> The IESG <iesg@ietf.org>
14.2. Media type application/yin+xml 15.2. Media type application/yin+xml
MIME media type name: application MIME media type name: application
MIME subtype name: yin+xml MIME subtype name: yin+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: Optional parameters:
"charset": This parameter has identical semantics to the "charset": This parameter has identical semantics to the
charset parameter of the "application/xml" media type as charset parameter of the "application/xml" media type as
skipping to change at page 167, line 5 skipping to change at page 176, line 5
Intended usage: COMMON Intended usage: COMMON
Author: Author:
This specification is a work item of the IETF NETMOD working This specification is a work item of the IETF NETMOD working
group, with mailing list address <netmod@ietf.org>. group, with mailing list address <netmod@ietf.org>.
Change controller: Change controller:
The IESG <iesg@ietf.org> The IESG <iesg@ietf.org>
15. Security Considerations 16. Security Considerations
This document defines a language with which to write and read This document defines a language with which to write and read
descriptions of management information. The language itself has no descriptions of management information. The language itself has no
security impact on the Internet. security impact on the Internet.
The same considerations are relevant as for the base NETCONF protocol The same considerations are relevant as for the base NETCONF protocol
(see [RFC6241], Section 9). (see [RFC6241], Section 9).
Data modeled in YANG might contain sensitive information. RPCs or Data modeled in YANG might contain sensitive information. RPCs or
notifications defined in YANG might transfer sensitive information. notifications defined in YANG might transfer sensitive information.
skipping to change at page 167, line 39 skipping to change at page 176, line 39
o adequate authentication and access control mechanisms to restrict o adequate authentication and access control mechanisms to restrict
the usage of sensitive data. the usage of sensitive data.
YANG parsers need to be robust with respect to malformed documents. YANG parsers need to be robust with respect to malformed documents.
Reading malformed documents from unknown or untrusted sources could Reading malformed documents from unknown or untrusted sources could
result in an attacker gaining privileges of the user running the YANG result in an attacker gaining privileges of the user running the YANG
parser. In an extreme situation, the entire machine could be parser. In an extreme situation, the entire machine could be
compromised. compromised.
16. Contributors 17. Contributors
The following people all contributed significantly to the initial The following people all contributed significantly to the initial
YANG document: YANG document:
- Andy Bierman (Brocade) - Andy Bierman (Brocade)
- Balazs Lengyel (Ericsson) - Balazs Lengyel (Ericsson)
- David Partain (Ericsson) - David Partain (Ericsson)
- Juergen Schoenwaelder (Jacobs University Bremen) - Juergen Schoenwaelder (Jacobs University Bremen)
- Phil Shafer (Juniper Networks) - Phil Shafer (Juniper Networks)
17. Acknowledgements 18. Acknowledgements
The editor wishes to thank the following individuals, who all The editor wishes to thank the following individuals, who all
provided helpful comments on various versions of this document: provided helpful comments on various versions of this document:
Mehmet Ersue, Washam Fan, Joel Halpern, 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.
18. ChangeLog 19. ChangeLog
RFC Editor: remove this section upon publication as an RFC. RFC Editor: remove this section upon publication as an RFC.
18.1. Version -00 19.1. Version -01
o Included solution Y01-01.
o Included solution Y03-01.
o Included solution Y06-02.
o Included solution Y07-01.
o Included solution Y14-01.
o Included solution Y20-01.
o Included solution Y23-01.
o Included solution Y29-01.
o Included solution Y30-01.
o Included solution Y31-01.
o Included solution Y35-01.
19.2. 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.
19. References 20. References
20.1. Normative References
19.1. Normative References
[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
skipping to change at page 169, line 37 skipping to change at page 179, line 16
Version 1.0", World Wide Web Consortium Recommendation Version 1.0", World Wide Web Consortium Recommendation
REC-xpath-19991116, November 1999, REC-xpath-19991116, November 1999,
<http://www.w3.org/TR/1999/REC-xpath-19991116>. <http://www.w3.org/TR/1999/REC-xpath-19991116>.
[XSD-TYPES] [XSD-TYPES]
Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Recommendation Second Edition", World Wide Web Consortium Recommendation
REC-xmlschema-2-20041028, October 2004, REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
19.2. Informative References 20.2. Informative References
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD
58, RFC 2579, April 1999. 58, RFC 2579, April 1999.
[RFC3780] Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation [RFC3780] Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation
 End of changes. 116 change blocks. 
259 lines changed or deleted 673 lines changed or added

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