draft-ietf-netmod-yang-04.txt   draft-ietf-netmod-yang-05.txt 
Network Working Group M. Bjorklund, Ed. Network Working Group M. Bjorklund, Ed.
Internet-Draft Tail-f Systems Internet-Draft Tail-f Systems
Intended status: Standards Track March 6, 2009 Intended status: Standards Track April 20, 2009
Expires: September 7, 2009 Expires: October 22, 2009
YANG - A data modeling language for NETCONF YANG - A data modeling language for NETCONF
draft-ietf-netmod-yang-04 draft-ietf-netmod-yang-05
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 7, 2009. This Internet-Draft will expire on October 22, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 4, line 14 skipping to change at page 4, line 14
7.7.2. The leaf-list's Substatements . . . . . . . . . . . . 64 7.7.2. The leaf-list's Substatements . . . . . . . . . . . . 64
7.7.3. The min-elements Statement . . . . . . . . . . . . . 64 7.7.3. The min-elements Statement . . . . . . . . . . . . . 64
7.7.4. The max-elements Statement . . . . . . . . . . . . . 64 7.7.4. The max-elements Statement . . . . . . . . . . . . . 64
7.7.5. The ordered-by Statement . . . . . . . . . . . . . . 65 7.7.5. The ordered-by Statement . . . . . . . . . . . . . . 65
7.7.6. XML Encoding Rules . . . . . . . . . . . . . . . . . 65 7.7.6. XML Encoding Rules . . . . . . . . . . . . . . . . . 65
7.7.7. NETCONF <edit-config> operations . . . . . . . . . . 65 7.7.7. NETCONF <edit-config> operations . . . . . . . . . . 65
7.7.8. Usage Example . . . . . . . . . . . . . . . . . . . . 66 7.7.8. Usage Example . . . . . . . . . . . . . . . . . . . . 66
7.8. The list Statement . . . . . . . . . . . . . . . . . . . 68 7.8. The list Statement . . . . . . . . . . . . . . . . . . . 68
7.8.1. The list's Substatements . . . . . . . . . . . . . . 69 7.8.1. The list's Substatements . . . . . . . . . . . . . . 69
7.8.2. The list's key Statement . . . . . . . . . . . . . . 69 7.8.2. The list's key Statement . . . . . . . . . . . . . . 69
7.8.3. The lists's unique Statement . . . . . . . . . . . . 70 7.8.3. The list's unique Statement . . . . . . . . . . . . . 70
7.8.4. The list's Child Node Statements . . . . . . . . . . 71 7.8.4. The list's Child Node Statements . . . . . . . . . . 71
7.8.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 71 7.8.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 71
7.8.6. NETCONF <edit-config> operations . . . . . . . . . . 72 7.8.6. NETCONF <edit-config> operations . . . . . . . . . . 72
7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 72 7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 72
7.9. The choice Statement . . . . . . . . . . . . . . . . . . 76 7.9. The choice Statement . . . . . . . . . . . . . . . . . . 76
7.9.1. The choice's Substatements . . . . . . . . . . . . . 76 7.9.1. The choice's Substatements . . . . . . . . . . . . . 76
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 . . . . . . . . . . . 78 7.9.3. The choice's default Statement . . . . . . . . . . . 78
7.9.4. The choice's mandatory Statement . . . . . . . . . . 79 7.9.4. The choice's mandatory Statement . . . . . . . . . . 79
7.9.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 80 7.9.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 80
skipping to change at page 4, line 51 skipping to change at page 4, line 51
7.13.1. The rpc's Substatements . . . . . . . . . . . . . . . 88 7.13.1. The rpc's Substatements . . . . . . . . . . . . . . . 88
7.13.2. The input Statement . . . . . . . . . . . . . . . . . 88 7.13.2. The input Statement . . . . . . . . . . . . . . . . . 88
7.13.3. The output Statement . . . . . . . . . . . . . . . . 89 7.13.3. The output Statement . . . . . . . . . . . . . . . . 89
7.13.4. XML Encoding Rules . . . . . . . . . . . . . . . . . 90 7.13.4. XML Encoding Rules . . . . . . . . . . . . . . . . . 90
7.13.5. Usage Example . . . . . . . . . . . . . . . . . . . . 90 7.13.5. Usage Example . . . . . . . . . . . . . . . . . . . . 90
7.14. The notification Statement . . . . . . . . . . . . . . . 91 7.14. The notification Statement . . . . . . . . . . . . . . . 91
7.14.1. The notification's Substatements . . . . . . . . . . 92 7.14.1. The notification's Substatements . . . . . . . . . . 92
7.14.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 92 7.14.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 92
7.14.3. Usage Example . . . . . . . . . . . . . . . . . . . . 92 7.14.3. Usage Example . . . . . . . . . . . . . . . . . . . . 92
7.15. The augment Statement . . . . . . . . . . . . . . . . . . 93 7.15. The augment Statement . . . . . . . . . . . . . . . . . . 93
7.15.1. The augment's Substatements . . . . . . . . . . . . . 94 7.15.1. The augment's Substatements . . . . . . . . . . . . . 95
7.15.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 94 7.15.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 95
7.15.3. Usage Example . . . . . . . . . . . . . . . . . . . . 95 7.15.3. Usage Example . . . . . . . . . . . . . . . . . . . . 95
7.16. The identity Statement . . . . . . . . . . . . . . . . . 97 7.16. The identity Statement . . . . . . . . . . . . . . . . . 97
7.16.1. The identity's Substatements . . . . . . . . . . . . 97 7.16.1. The identity's Substatements . . . . . . . . . . . . 98
7.16.2. The base Statement . . . . . . . . . . . . . . . . . 97 7.16.2. The base Statement . . . . . . . . . . . . . . . . . 98
7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . . 98 7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . . 99
7.17. The extension Statement . . . . . . . . . . . . . . . . . 98 7.17. The extension Statement . . . . . . . . . . . . . . . . . 99
7.17.1. The extension's Substatements . . . . . . . . . . . . 99 7.17.1. The extension's Substatements . . . . . . . . . . . . 100
7.17.2. The argument Statement . . . . . . . . . . . . . . . 99 7.17.2. The argument Statement . . . . . . . . . . . . . . . 100
7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . . 100 7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . . 101
7.18. Conformance-related Statements . . . . . . . . . . . . . 100 7.18. Conformance-related Statements . . . . . . . . . . . . . 101
7.18.1. The feature Statement . . . . . . . . . . . . . . . . 100 7.18.1. The feature Statement . . . . . . . . . . . . . . . . 101
7.18.2. The if-feature Statement . . . . . . . . . . . . . . 102 7.18.2. The if-feature Statement . . . . . . . . . . . . . . 103
7.18.3. The deviation Statement . . . . . . . . . . . . . . . 102 7.18.3. The deviation Statement . . . . . . . . . . . . . . . 103
7.19. Common Statements . . . . . . . . . . . . . . . . . . . . 105 7.19. Common Statements . . . . . . . . . . . . . . . . . . . . 106
7.19.1. The config Statement . . . . . . . . . . . . . . . . 105 7.19.1. The config Statement . . . . . . . . . . . . . . . . 106
7.19.2. The status Statement . . . . . . . . . . . . . . . . 105 7.19.2. The status Statement . . . . . . . . . . . . . . . . 106
7.19.3. The description Statement . . . . . . . . . . . . . . 106 7.19.3. The description Statement . . . . . . . . . . . . . . 107
7.19.4. The reference Statement . . . . . . . . . . . . . . . 106 7.19.4. The reference Statement . . . . . . . . . . . . . . . 107
7.19.5. The when Statement . . . . . . . . . . . . . . . . . 106 7.19.5. The when Statement . . . . . . . . . . . . . . . . . 107
8. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 109 8. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 110
8.1. Constraints on Data . . . . . . . . . . . . . . . . . . . 109 8.1. Constraints on Data . . . . . . . . . . . . . . . . . . . 110
8.2. Hierarchy of Constraints . . . . . . . . . . . . . . . . 109 8.2. Hierarchy of Constraints . . . . . . . . . . . . . . . . 110
8.3. Constraint Enforcement Model . . . . . . . . . . . . . . 109 8.3. Constraint Enforcement Model . . . . . . . . . . . . . . 110
8.3.1. Payload Parsing . . . . . . . . . . . . . . . . . . . 110 8.3.1. Payload Parsing . . . . . . . . . . . . . . . . . . . 111
8.3.2. NETCONF <edit-config> Processing . . . . . . . . . . 110 8.3.2. NETCONF <edit-config> Processing . . . . . . . . . . 111
8.3.3. Validation . . . . . . . . . . . . . . . . . . . . . 111 8.3.3. Validation . . . . . . . . . . . . . . . . . . . . . 112
9. Built-in Types . . . . . . . . . . . . . . . . . . . . . . . 112 9. Built-in Types . . . . . . . . . . . . . . . . . . . . . . . 113
9.1. Canonical representation . . . . . . . . . . . . . . . . 112 9.1. Canonical representation . . . . . . . . . . . . . . . . 113
9.2. The Integer Built-in Types . . . . . . . . . . . . . . . 112 9.2. The Integer Built-in Types . . . . . . . . . . . . . . . 113
9.2.1. Lexicographic Representation . . . . . . . . . . . . 113 9.2.1. Lexicographic Representation . . . . . . . . . . . . 114
9.2.2. Canonical Form . . . . . . . . . . . . . . . . . . . 114 9.2.2. Canonical Form . . . . . . . . . . . . . . . . . . . 115
9.2.3. Restrictions . . . . . . . . . . . . . . . . . . . . 114 9.2.3. Restrictions . . . . . . . . . . . . . . . . . . . . 115
9.2.4. The range Statement . . . . . . . . . . . . . . . . . 114 9.2.4. The range Statement . . . . . . . . . . . . . . . . . 115
9.2.5. Usage Example . . . . . . . . . . . . . . . . . . . . 115 9.2.5. Usage Example . . . . . . . . . . . . . . . . . . . . 116
9.3. The Floating Point Built-in Types . . . . . . . . . . . . 115 9.3. The decimal64 Built-in Type . . . . . . . . . . . . . . . 116
9.3.1. Lexicographic Representation . . . . . . . . . . . . 115 9.3.1. Lexicographic Representation . . . . . . . . . . . . 116
9.3.2. Canonical Form . . . . . . . . . . . . . . . . . . . 115 9.3.2. Canonical Form . . . . . . . . . . . . . . . . . . . 116
9.3.3. Restrictions . . . . . . . . . . . . . . . . . . . . 115 9.3.3. Restrictions . . . . . . . . . . . . . . . . . . . . 116
9.3.4. Usage Example . . . . . . . . . . . . . . . . . . . . 116 9.3.4. The fraction-digits Statement . . . . . . . . . . . . 117
9.4. The string Built-in Type . . . . . . . . . . . . . . . . 116 9.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 117
9.4.1. Lexicographic Representation . . . . . . . . . . . . 116 9.4. The string Built-in Type . . . . . . . . . . . . . . . . 117
9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 116 9.4.1. Lexicographic Representation . . . . . . . . . . . . 117
9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 116 9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 117
9.4.4. The length Statement . . . . . . . . . . . . . . . . 116 9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 117
9.4.5. Usage Example . . . . . . . . . . . . . . . . . . . . 117 9.4.4. The length Statement . . . . . . . . . . . . . . . . 117
9.4.6. The pattern Statement . . . . . . . . . . . . . . . . 118 9.4.5. Usage Example . . . . . . . . . . . . . . . . . . . . 119
9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 118 9.4.6. The pattern Statement . . . . . . . . . . . . . . . . 119
9.5. The boolean Built-in Type . . . . . . . . . . . . . . . . 119 9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 120
9.5.1. Lexicographic Representation . . . . . . . . . . . . 119 9.5. The boolean Built-in Type . . . . . . . . . . . . . . . . 120
9.5.2. Restrictions . . . . . . . . . . . . . . . . . . . . 119 9.5.1. Lexicographic Representation . . . . . . . . . . . . 120
9.6. The enumeration Built-in Type . . . . . . . . . . . . . . 119 9.5.2. Restrictions . . . . . . . . . . . . . . . . . . . . 120
9.6.1. Lexicographic Representation . . . . . . . . . . . . 119 9.6. The enumeration Built-in Type . . . . . . . . . . . . . . 120
9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 119 9.6.1. Lexicographic Representation . . . . . . . . . . . . 120
9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 119 9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 120
9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 119 9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 121
9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 120 9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 121
9.7. The bits Built-in Type . . . . . . . . . . . . . . . . . 121 9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 122
9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 121 9.7. The bits Built-in Type . . . . . . . . . . . . . . . . . 122
9.7.2. Lexicographic Representation . . . . . . . . . . . . 121 9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 122
9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 121 9.7.2. Lexicographic Representation . . . . . . . . . . . . 122
9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 121 9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 122
9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 122 9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 122
9.8. The binary Built-in Type . . . . . . . . . . . . . . . . 122 9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 123
9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 123 9.8. The binary Built-in Type . . . . . . . . . . . . . . . . 124
9.8.2. Lexicographic Representation . . . . . . . . . . . . 123 9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 124
9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 123 9.8.2. Lexicographic Representation . . . . . . . . . . . . 124
9.9. The leafref Built-in Type . . . . . . . . . . . . . . . . 123 9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 124
9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 123 9.9. The leafref Built-in Type . . . . . . . . . . . . . . . . 124
9.9.2. The path Statement . . . . . . . . . . . . . . . . . 123 9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 125
9.9.3. The require-instance Statement . . . . . . . . . . . 124 9.9.2. The path Statement . . . . . . . . . . . . . . . . . 125
9.9.4. Lexicographic Representation . . . . . . . . . . . . 124 9.9.3. The require-instance Statement . . . . . . . . . . . 125
9.9.5. Canonical Form . . . . . . . . . . . . . . . . . . . 124 9.9.4. Lexicographic Representation . . . . . . . . . . . . 126
9.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 124 9.9.5. Canonical Form . . . . . . . . . . . . . . . . . . . 126
9.10. The identityref Built-in Type . . . . . . . . . . . . . . 127 9.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 126
9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 127 9.10. The identityref Built-in Type . . . . . . . . . . . . . . 128
9.10.2. The identityref's base Statement . . . . . . . . . . 127 9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 128
9.10.3. Lexicographic Representation . . . . . . . . . . . . 127 9.10.2. The identityref's base Statement . . . . . . . . . . 128
9.10.4. Canonical Form . . . . . . . . . . . . . . . . . . . 127 9.10.3. Lexicographic Representation . . . . . . . . . . . . 129
9.10.5. Usage Example . . . . . . . . . . . . . . . . . . . . 127 9.10.4. Canonical Form . . . . . . . . . . . . . . . . . . . 129
9.11. The empty Built-in Type . . . . . . . . . . . . . . . . . 128 9.10.5. Usage Example . . . . . . . . . . . . . . . . . . . . 129
9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 129 9.11. The empty Built-in Type . . . . . . . . . . . . . . . . . 130
9.11.2. Lexicographic Representation . . . . . . . . . . . . 129 9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 130
9.11.3. Canonical Form . . . . . . . . . . . . . . . . . . . 129 9.11.2. Lexicographic Representation . . . . . . . . . . . . 130
9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . . 129 9.11.3. Canonical Form . . . . . . . . . . . . . . . . . . . 130
9.12. The union Built-in Type . . . . . . . . . . . . . . . . . 129 9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . . 130
9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 130 9.12. The union Built-in Type . . . . . . . . . . . . . . . . . 130
9.12.2. Lexicographic Representation . . . . . . . . . . . . 130 9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 131
9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 130 9.12.2. Lexicographic Representation . . . . . . . . . . . . 131
9.13. The instance-identifier Built-in Type . . . . . . . . . . 130 9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 131
9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 130 9.13. The instance-identifier Built-in Type . . . . . . . . . . 131
9.13.2. Lexicographic Representation . . . . . . . . . . . . 131 9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 132
9.13.3. Canonical Form . . . . . . . . . . . . . . . . . . . 131 9.13.2. Lexicographic Representation . . . . . . . . . . . . 132
9.13.4. Usage Example . . . . . . . . . . . . . . . . . . . . 131 9.13.3. Canonical Form . . . . . . . . . . . . . . . . . . . 132
10. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 132 9.13.4. Usage Example . . . . . . . . . . . . . . . . . . . . 132
11. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 10. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 134
11.1. Formal YIN Definition . . . . . . . . . . . . . . . . . . 135 11. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
11.1.1. Usage Example . . . . . . . . . . . . . . . . . . . . 137 11.1. Formal YIN Definition . . . . . . . . . . . . . . . . . . 137
12. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 139 11.1.1. Usage Example . . . . . . . . . . . . . . . . . . . . 139
13. Error Responses for YANG Related Errors . . . . . . . . . . . 161 12. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 141
13. Error Responses for YANG Related Errors . . . . . . . . . . . 162
13.1. Error Message for Data that Violates a unique 13.1. Error Message for Data that Violates a unique
Statement: . . . . . . . . . . . . . . . . . . . . . . . 161 Statement: . . . . . . . . . . . . . . . . . . . . . . . 162
13.2. Error Message for Data that Violates a max-elements 13.2. Error Message for Data that Violates a max-elements
Statement: . . . . . . . . . . . . . . . . . . . . . . . 161 Statement: . . . . . . . . . . . . . . . . . . . . . . . 162
13.3. Error Message for Data that Violates a min-elements 13.3. Error Message for Data that Violates a min-elements
Statement: . . . . . . . . . . . . . . . . . . . . . . . 161 Statement: . . . . . . . . . . . . . . . . . . . . . . . 162
13.4. Error Message for Data that Violates a must statement: . 162 13.4. Error Message for Data that Violates a must statement: . 163
13.5. Error Message for Data that Violates a 13.5. Error Message for Data that Violates a
require-instance statement: . . . . . . . . . . . . . . . 162 require-instance statement: . . . . . . . . . . . . . . . 163
13.6. Error Message for Data that Violates a mandatory 13.6. Error Message for Data that Violates a mandatory
choice statement: . . . . . . . . . . . . . . . . . . . . 162 choice statement: . . . . . . . . . . . . . . . . . . . . 163
13.7. Error Message for the "insert" Operation . . . . . . . . 162 13.7. Error Message for the "insert" Operation . . . . . . . . 163
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 163 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 164
15. Security Considerations . . . . . . . . . . . . . . . . . . . 164 15. Security Considerations . . . . . . . . . . . . . . . . . . . 165
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 165 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 166
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 166 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 167
17.1. Normative References . . . . . . . . . . . . . . . . . . 166 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 168
17.2. Non-Normative References . . . . . . . . . . . . . . . . 167 18.1. Normative References . . . . . . . . . . . . . . . . . . 168
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 168 18.2. Non-Normative References . . . . . . . . . . . . . . . . 169
A.1. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 168 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 170
A.2. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 168 A.1. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 170
A.3. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 169 A.2. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 170
A.4. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 169 A.3. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 171
A.5. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 170 A.4. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 171
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 171 A.5. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 171
A.6. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 172
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 174
1. Introduction 1. Introduction
Today, the NETCONF protocol [RFC4741] lacks a standardized way to Today, the NETCONF protocol [RFC4741] lacks a standardized way to
create data models. Instead, vendors are forced to use proprietary create data models. Instead, vendors are forced to use proprietary
solutions. In order for NETCONF to be a interoperable protocol, solutions. In order for NETCONF to be a interoperable protocol,
models must be defined in a vendor-neutral way. YANG provides the models must be defined in a vendor-neutral way. YANG provides the
language and rules for defining such models for use with NETCONF. language and rules for defining such models for use with NETCONF.
YANG is a data modeling language used to model configuration and YANG is a data modeling language used to model configuration and
state data manipulated by the NETCONF protocol, NETCONF remote state data manipulated by the NETCONF protocol, NETCONF remote
procedure calls, and NETCONF notifications. This document describes procedure calls, and NETCONF notifications. YANG models the
the syntax and semantics of the YANG language, how the data model operations and content layers of NETCONF (see the NETCONF protocol
defined in a YANG module is represented in XML, and how NETCONF [RFC4741], section 1.1).
operations are used to manipulate the data.
This document describes the syntax and semantics of the YANG
language, how the data model defined in a YANG module is represented
in XML, and how NETCONF operations are used to manipulate the data.
2. Key Words 2. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "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
skipping to change at page 20, line 11 skipping to change at page 20, line 11
programming languages, but with some differences due to special programming languages, but with some differences due to special
requirements from the management domain. The following table requirements from the management domain. The following table
summarizes the built-in types discussed in Section 9: summarizes the built-in types discussed in Section 9:
+---------------------+-------------+-------------------------------+ +---------------------+-------------+-------------------------------+
| Name | Type | Description | | Name | Type | Description |
+---------------------+-------------+-------------------------------+ +---------------------+-------------+-------------------------------+
| binary | Text | Any binary data | | binary | Text | Any binary data |
| bits | Text/Number | A set of bits or flags | | bits | Text/Number | A set of bits or flags |
| boolean | Text | "true" or "false" | | boolean | Text | "true" or "false" |
| decimal64 | Number | 64-bit signed decimal number |
| empty | Empty | A leaf that does not have any | | empty | Empty | A leaf that does not have any |
| | | value | | | | value |
| enumeration | Text/Number | Enumerated strings with | | enumeration | Text/Number | Enumerated strings with |
| | | associated numeric values | | | | associated numeric values |
| float32 | Number | 32-bit IEEE floating point |
| | | real number |
| float64 | Number | 64-bit IEEE floating point |
| | | real number |
| identityref | Text | A reference to an abstract | | identityref | Text | A reference to an abstract |
| | | identity | | | | identity |
| instance-identifier | Text | References a data tree node | | instance-identifier | Text | References a data tree node |
| int8 | Number | 8-bit signed integer | | int8 | Number | 8-bit signed integer |
| int16 | Number | 16-bit signed integer | | int16 | Number | 16-bit signed integer |
| int32 | Number | 32-bit signed integer | | int32 | Number | 32-bit signed integer |
| int64 | Number | 64-bit signed integer | | int64 | Number | 64-bit signed integer |
| leafref | Text/Number | A reference to a leaf | | leafref | Text/Number | A reference to a leaf |
| | | instance | | | | instance |
| string | Text | Human readable string | | string | Text | Human readable string |
skipping to change at page 30, line 13 skipping to change at page 30, line 13
submodule compilation may be delayed until the submodules are linked submodule compilation may be delayed until the submodules are linked
into a cohesive module. into a cohesive module.
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 standard modules MUST be assigned by IANA. Namespaces for modules published in RFC streams MUST be assigned by
IANA, see Section 14.
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. It is RECOMMENDED to owning the module without a central registry. It is RECOMMENDED to
choose namespaces that will have a low probability of colliding with choose namespaces that will have a low probability of colliding with
standard or other enterprise modules, e.g. by using the enterprise or standard or other enterprise modules, e.g. by using the enterprise or
organization name in the namespace. organization name in the namespace.
The "namespace" statement is covered in Section 7.1.3. The "namespace" statement is covered in Section 7.1.3.
5.3.1. YANG XML Namespace 5.3.1. YANG XML Namespace
YANG defines its own XML namespace for NETCONF <edit-config> YANG defines its own XML namespace for NETCONF <edit-config>
operations. This namespace is "urn:ietf:params:xml:ns:yang:1" [XXX operations. This namespace is "urn:ietf:params:xml:ns:yang:1".
IANA].
5.4. Resolving Grouping, Type, and Identity Names 5.4. Resolving Grouping, Type, and Identity Names
Grouping, type, and identity names are resolved in the context in Grouping, type, and identity names are resolved in the context in
which they are defined, rather than the context in which they are which they are defined, rather than the context in which they are
used. Users of groupings, typedefs, and identities are not required used. Users of groupings, typedefs, and identities are not required
to import modules or include submodules to satisfy all references to import modules or include submodules to satisfy all references
made by the original definition. This behaves like static scoping in made by the original definition. This behaves like static scoping in
a conventional programming language. a conventional programming language.
skipping to change at page 32, line 34 skipping to change at page 32, line 34
behavior to the device. behavior to the device.
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
feature. If the device supports a feature, then the corresponding feature. 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 "if- the module that are conditional to the feature are noted by the
feature" statement with the name of the feature as its argument. "if-feature" statement with the name of the feature as its argument.
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
willing to implement the model as written. For YANG-based automation willing to implement the model as written. For YANG-based automation
to deal with these device deviations, a mechanism must exist for to deal with these device deviations, a mechanism must exist for
skipping to change at page 38, line 11 skipping to change at page 38, line 11
second line" second line"
"first line\n" + " second line" "first line\n" + " second line"
6.2. Identifiers 6.2. Identifiers
Identifiers are used to identify different kinds of YANG items by Identifiers are used to identify different kinds of YANG items by
name. Each identifier starts with an upper-case or lower-case ASCII name. Each identifier starts with an upper-case or lower-case ASCII
letter or an underscore character, followed by zero or more ASCII letter or an underscore character, followed by zero or more ASCII
letters, digits, underscore characters, hyphens, and dots. letters, digits, underscore characters, hyphens, and dots.
Implementations MUST support identifiers up to 63 characters in Implementations MUST support identifiers up to 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 12. Identifiers
can be specified as quoted or unquoted strings. can be specified as quoted or unquoted strings.
6.2.1. Identifiers and their namespaces 6.2.1. Identifiers and their namespaces
Each identifier is valid in a namespace which depends on the type of Each identifier is valid in a namespace which depends on the type of
the YANG item being defined: the YANG item being defined:
o All module and submodule names share the same global module o All module and submodule names share the same global module
skipping to change at page 41, line 27 skipping to change at page 41, line 27
} }
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 which belong to the module together. The "module" statements which 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.
Standard module names MUST be assigned by IANA. Names of modules published in RFC streams MUST be assigned by IANA,
see Section 14.
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
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. the enterprise or organization name as a prefix.
A module SHOULD have the following layout: A module SHOULD have the following layout:
module <module-name> { module <module-name> {
skipping to change at page 48, line 6 skipping to change at page 48, line 6
module that includes the submodules. module that includes the submodules.
The "submodule" statement is used to give the submodule a name, and The "submodule" statement is used to give the submodule a name, and
to group all statements which belong to the submodule together. to group all statements which belong to the submodule together.
The "submodule" statement, which MUST be present at most once, takes The "submodule" statement, which MUST be present at most once, takes
as an argument an identifier which is the name of the submodule, as an argument an identifier which 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. information.
Standard submodule names MUST be assigned by IANA. Names of submodules published in RFC streams MUST be assigned by
IANA, see Section 14.
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. the enterprise or organization name as a prefix.
A submodule SHOULD have the following layout: A submodule SHOULD have the following layout:
submodule <module-name> { submodule <module-name> {
skipping to change at page 57, line 31 skipping to change at page 57, line 31
"uses", and "choice" statements can be used to define child nodes to "uses", and "choice" statements can be used to define child nodes to
the container. the container.
7.5.7. XML Encoding Rules 7.5.7. XML Encoding Rules
A container node is encoded as an XML element. The element's name is A container node is encoded as an XML element. The element's name is
the container's identifier, and its XML namespace is the module's XML the container's identifier, and its XML namespace is the module's XML
namespace. namespace.
The container's child nodes are encoded as subelements to the The container's child nodes are encoded as subelements to the
container element, in the same order as they are defined within the container element. If the container defines RPC input or output
container statement. parameters, the subelements are encoded in the same order as they are
defined within the container statement. Otherwise, the subelements
are encoded in any order.
A NETCONF server that replies to a <get> or <get-config> request MAY A NETCONF server that replies to a <get> or <get-config> request MAY
choose not to send a container element if the container node does not choose not to send a container element if the container node does not
have the "presence" statement and no child nodes exist. Thus, a have the "presence" statement and no child nodes exist. Thus, a
client that receives an <rpc-reply> for a <get> or <get-config> client that receives an <rpc-reply> for a <get> or <get-config>
request, must be prepared to handle the case that a container node request, must be prepared to handle the case that a container node
without a presence statement is not present in the XML. without a presence statement is not present in the XML.
7.5.8. NETCONF <edit-config> Operations 7.5.8. NETCONF <edit-config> Operations
skipping to change at page 60, line 49 skipping to change at page 60, line 49
"mandatory" is true. "mandatory" is true.
7.6.4. The leaf's mandatory Statement 7.6.4. The leaf's mandatory Statement
The "mandatory" statement, which is optional, takes as an argument The "mandatory" statement, which is optional, takes as an argument
the string "true" or "false", and puts a constraint on valid data. the string "true" or "false", and puts a constraint on valid data.
If not specified, the default is "false". If not specified, the default is "false".
If "mandatory" is "true", the behavior of the constraint depends on If "mandatory" is "true", the behavior of the constraint depends on
the type of the leaf's closest ancestor node in the schema tree which the type of the leaf's closest ancestor node in the schema tree which
is not a presence container (see Section 7.5.1): is not a non-presence container (see Section 7.5.1):
o If this ancestor is a case node, the leaf MUST exist if any other o If this ancestor is a case node, the leaf MUST exist if any other
node from the case exists. node from the case exists.
o Otherwise, the leaf MUST exist if the ancestor node exists. o Otherwise, the leaf MUST exist if the ancestor node exists.
This constraint is enforced according to the rules in Section 8. This constraint is enforced according to the rules in Section 8.
7.6.5. XML Encoding Rules 7.6.5. XML Encoding Rules
skipping to change at page 62, line 15 skipping to change at page 62, line 15
leaf port { leaf port {
type inet:port-number; type inet:port-number;
default 22; default 22;
description "The port which the SSH server listens to" description "The port which the SSH server listens to"
} }
A corresponding XML encoding: A corresponding XML encoding:
<port>2022</port> <port>2022</port>
To create a leaf with an edit-config: To create a leaf with an <edit-config>:
<rpc message-id="101" <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config> <edit-config>
<target> <target>
<running/> <running/>
</target> </target>
<config> <config>
<system xmlns="http://example.com/schema/config"> <system xmlns="http://example.com/schema/config">
skipping to change at page 64, line 34 skipping to change at page 64, line 34
7.7.3. The min-elements Statement 7.7.3. The min-elements Statement
The "min-elements" statement, which is optional, takes as an argument The "min-elements" statement, which is optional, takes as an argument
a non-negative integer which puts a constraint on valid list entries. a non-negative integer which puts a constraint on valid list entries.
A valid leaf-list or list MUST have least min-elements entries. A valid leaf-list or list MUST have least min-elements entries.
If no "min-elements" statement is present, it defaults to zero. If no "min-elements" statement is present, it defaults to zero.
The behavior of the constraint depends on the type of the leaf-list's The behavior of the constraint depends on the type of the leaf-list's
or list's closest ancestor node in the schema tree which is not a or list's closest ancestor node in the schema tree which is not a
presence container (see Section 7.5.1): non-presence container (see Section 7.5.1):
o If this ancestor is a case node, the constraint is enforced if any o If this ancestor is a case node, the constraint is enforced if any
other node from the case exists. other node from the case exists.
o Otherwise, it is enforced if the ancestor node exists. o Otherwise, it is enforced if the ancestor node exists.
The constraint is further enforced according to the rules in The constraint is further enforced according to the rules in
Section 8. Section 8.
7.7.4. The max-elements Statement 7.7.4. The max-elements Statement
skipping to change at page 70, line 8 skipping to change at page 70, line 8
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 12.
7.8.3. The lists'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 which contains a space entries. It takes as an argument a string which 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 12). 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.
skipping to change at page 72, line 6 skipping to change at page 72, line 6
A list is encoded as a series of XML elements, one for each entry in A list is encoded as a series of XML elements, one for each entry in
the list. Each element's name is the list's identifier, and its XML the list. Each element's name is the list's identifier, and its XML
namespace is the module's XML namespace. namespace is the module's XML namespace.
The list's key nodes are encoded as subelements to the list's The list's key nodes are encoded as subelements to the list's
identifier element, in the same order as they are defined within the identifier element, in the same order as they are defined within the
key statement. key statement.
The rest of the list's child nodes are encoded as subelements to the The rest of the list's child nodes are encoded as subelements to the
list element, after the keys, in the same order as they are defined list element, after the keys. If the list defines RPC input or
within the list statement. output parameters, the subelements are encoded in the same order as
they are defined within the list statement. Otherwise, the
subelements are encoded in any order.
7.8.6. NETCONF <edit-config> operations 7.8.6. NETCONF <edit-config> operations
List entries can be created, deleted, replaced and modified through List entries can be created, deleted, replaced and modified through
<edit-config>, by using the "operation" attribute in the list's XML <edit-config>, by using the "operation" attribute in the list's XML
element. In each case, the values of all keys are used to uniquely element. In each case, the values of all keys are used to uniquely
identify a list entry. If all keys are not specified for a list identify a list entry. If all keys are not specified for a list
entry, a "missing-element" error is returned. entry, a "missing-element" error is returned.
In an "ordered-by user" list, the attributes "insert" and "key" in In an "ordered-by user" list, the attributes "insert" and "key" in
skipping to change at page 76, line 51 skipping to change at page 76, line 51
7.9.2. The choice's case Statement 7.9.2. The choice's case Statement
The "case" statement is used to define branches of the choice. It The "case" statement is used to define branches of the choice. It
takes as an argument an identifier, followed by a block of takes as an argument an identifier, followed by a block of
substatements that holds detailed case information. substatements that holds detailed case information.
The identifier is used to identify the case node in the schema tree. The identifier is used to identify the case node in the schema tree.
A case node does not exist in the data tree. A case node does not exist in the data tree.
Within a "case" statement, the "anyxml", "container", "leaf", "list", Within a "case" statement, the "anyxml", "container", "leaf", "list",
"leaf-list", "uses", and "augment" statements can be used to define "leaf-list", and "uses" statements can be used to define child nodes
child nodes to the case node. The identifiers of all these child to the case node. The identifiers of all these child nodes MUST be
nodes MUST be unique within all cases in a choice. For example, the unique within all cases in a choice. For example, the following is
following is illegal: illegal:
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 "leaf- contains a single "anyxml", "container", "leaf", "list", or
list" statement. In this case, the identifier of the case node is "leaf-list" statement. In this case, the identifier of the case node
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:
choice interface-type { choice interface-type {
case ethernet { case ethernet {
skipping to change at page 79, line 43 skipping to change at page 79, line 43
7.9.4. The choice's mandatory Statement 7.9.4. The choice's mandatory Statement
The "mandatory" statement, which is optional, takes as an argument The "mandatory" statement, which is optional, takes as an argument
the string "true" or "false", and puts a constraint on valid data. the string "true" or "false", and puts a constraint on valid data.
If "mandatory" is "true", at least one node from exactly one of the If "mandatory" is "true", at least one node from exactly one of the
choice's case branches MUST exist. choice's case branches MUST exist.
If not specified, the default is "false". If not specified, the default is "false".
The behavior of the constraint depends on the type of the choice's The behavior of the constraint depends on the type of the choice's
closest ancestor node in the schema tree which is not a presence closest ancestor node in the schema tree which is not a non-presence
container (see Section 7.5.1): container (see Section 7.5.1):
o If this ancestor is a case node, the constraint is enforced if any o If this ancestor is a case node, the constraint is enforced if any
other node from the case exists. other node from the case exists.
o Otherwise, it is enforced if the ancestor node exists. o Otherwise, it is enforced if the ancestor node exists.
The constraint is further enforced according to the rules in The constraint is further enforced according to the rules in
Section 8. Section 8.
skipping to change at page 81, line 30 skipping to change at page 81, line 30
</rpc> </rpc>
7.10. The anyxml Statement 7.10. The anyxml Statement
The "anyxml" statement defines an interior node in the schema tree. The "anyxml" statement defines an interior node in the schema tree.
It takes one argument, which is an identifier, followed by a block of It takes one argument, which is an identifier, followed by a block of
substatements that holds detailed anyxml information. substatements that holds detailed anyxml information.
The anyxml statement is used to represent an unknown chunk of XML. The anyxml statement is used to represent an unknown chunk of XML.
No restrictions are placed on the XML. This can be useful in e.g. No restrictions are placed on the XML. This can be useful in e.g.
RPC replies. An example is the <filter> parameter in the <get- RPC replies. An example is the <filter> parameter in the
config> operation. <get-config> operation.
An anyxml node cannot be augmented. An anyxml node cannot be augmented.
Since the use of anyxml limits the manipulation of the content, it is Since the use of anyxml limits the manipulation of the content, it is
RECOMMENDED that the anyxml statement not be used to represent RECOMMENDED that the anyxml statement not be used to represent
configuration data. configuration data.
7.10.1. The anyxml's Substatements 7.10.1. The anyxml's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
skipping to change at page 88, line 26 skipping to change at page 88, line 26
| status | 7.19.2 | 0..1 | | status | 7.19.2 | 0..1 |
| typedef | 7.3 | 0..n | | typedef | 7.3 | 0..n |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.13.2. The input Statement 7.13.2. The input Statement
The "input" statement, which is optional, is used to define input The "input" statement, which is optional, is used to define input
parameters to the RPC method. It does not take an argument. The parameters to the RPC method. It does not take an argument. The
substatements to "input" defines nodes under the RPC's input node. substatements to "input" defines nodes under the RPC's input node.
If a container in the input tree has a "presence" statement, the
container need not be present in a NETCONF RPC invocation.
If a leaf in the input tree has a "mandatory" statement with the If a leaf in the input tree has a "mandatory" statement with the
value "true", the leaf MUST be present in a NETCONF RPC invocation. value "true", the leaf MUST be present in a NETCONF RPC invocation.
If a leaf in the input tree has a default value, the NETCONF server If a leaf in the input tree has a default value, the NETCONF server
MUST internally use this default if the leaf is not present in a MUST internally use this default if the leaf is not present in a
NETCONF RPC invocation. NETCONF RPC invocation.
If a "config" statement is present for any node in the input tree, it If a "config" statement is present for any node in the input tree, it
is ignored. is ignored.
If any node has a "when" statement which would evaluate to false,
then this node MUST NOT be present in the input tree.
7.13.2.1. The input's Substatements 7.13.2.1. The input's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| grouping | 7.11 | 0..n | | grouping | 7.11 | 0..n |
| leaf | 7.6 | 0..n | | leaf | 7.6 | 0..n |
skipping to change at page 89, line 27 skipping to change at page 89, line 27
| typedef | 7.3 | 0..n | | typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n | | uses | 7.12 | 0..n |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.13.3. The output Statement 7.13.3. The output Statement
The "output" statement, which is optional, is used to define output The "output" statement, which is optional, is used to define output
parameters to the RPC method. It does not take an argument. The parameters to the RPC method. It does not take an argument. The
substatements to "output" defines nodes under the RPC's output node. substatements to "output" defines nodes under the RPC's output node.
If a container in the output tree has a "presence" statement, the
container need not be present in a NETCONF RPC reply
If a leaf in the output tree has a "mandatory" statement with the If a leaf in the output tree has a "mandatory" statement with the
value "true", the leaf MUST be present in a NETCONF RPC reply. value "true", the leaf MUST be present in a NETCONF RPC reply.
If a leaf in the output tree has a default value, the NETCONF client If a leaf in the output tree has a default value, the NETCONF client
MUST internally use this default if the leaf is not present in a MUST internally use this default if the leaf is not present in a
NETCONF RPC reply. NETCONF RPC reply.
If a "config" statement is present for any node in the output tree, If a "config" statement is present for any node in the output tree,
it is ignored. it is ignored.
If any node has a "when" statement which would evaluate to false,
then this node MUST NOT be present in the output tree.
7.13.3.1. The output's Substatements 7.13.3.1. The output's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| grouping | 7.11 | 0..n | | grouping | 7.11 | 0..n |
| leaf | 7.6 | 0..n | | leaf | 7.6 | 0..n |
skipping to change at page 92, line 28 skipping to change at page 92, line 28
| list | 7.8 | 0..n | | list | 7.8 | 0..n |
| reference | 7.19.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.19.2 | 0..1 |
| typedef | 7.3 | 0..n | | typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n | | uses | 7.12 | 0..n |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.14.2. XML Encoding Rules 7.14.2. XML Encoding Rules
A notification node is encoded as a child XML element to the A notification node is encoded as a child XML element to the
<notification> element defined in [RFC5277]. The element's name is <notification> element defined in NETCONF Event Notifications
the notification's identifier, and its XML namespace is the module's [RFC5277]. The element's name is the notification's identifier, and
XML namespace. its XML namespace is the module's XML namespace.
The notifications's child nodes are encoded as subelements to the The notifications's child nodes are encoded as subelements to the
notification node's XML element, in the same order as they are notification node's XML element, in the same order as they are
defined within the notification statement. defined within the notification statement.
7.14.3. Usage Example 7.14.3. Usage Example
The following example defines a notification: The following example defines a notification:
module event { module event {
skipping to change at page 93, line 38 skipping to change at page 93, line 38
<reporting-entity> <reporting-entity>
<card>Ethernet0</card> <card>Ethernet0</card>
</reporting-entity> </reporting-entity>
<severity>major</severity> <severity>major</severity>
</event> </event>
</notification> </notification>
7.15. The augment Statement 7.15. The augment Statement
The "augment" statement allows a module or submodule to add to the The "augment" statement allows a module or submodule to add to the
schema tree defined in another module or submodule, and to add to the schema tree defined in an external module, or the current module and
nodes from a grouping in a "uses" statement. The argument is a its submodules, and to add to the nodes from a grouping in a "uses"
string which identifies a node in the schema tree. This node is statement. The argument is a string which identifies a node in the
called the augment's target node. The target node MUST be either a schema tree. This node is called the augment's target node. The
container, list, choice, case, input, output, or notification node. target node MUST be either a container, list, choice, case, input,
It is augmented with the nodes defined in the substatements that output, or notification node. It is augmented with the nodes defined
follow the "augment" statement. in the substatements that follow the "augment" statement.
The argument string is a schema node identifier. The syntax is The argument string is a schema node identifier. The syntax is
formally defined by the rule "augment-arg" in Section 12. If the formally defined by the rule "augment-arg" in Section 12. If the
"augment" statement is on the top-level in a module or submodule, the "augment" statement is on the top-level in a module or submodule, the
absolute form (defined by the rule "absolute-schema-nodeid" in absolute form (defined by the rule "absolute-schema-nodeid" in
Section 12) of a schema node identifier MUST be used. If the Section 12) of a schema node identifier MUST be used. If the
"augment" statement is in a "uses" statement, the descendant form "augment" statement is in a "uses" statement, the descendant form
(defined by the rule "descendant-schema-nodeid" in Section 12) MUST (defined by the rule "descendant-schema-nodeid" in Section 12) MUST
be used. be used.
skipping to change at page 94, line 21 skipping to change at page 94, line 21
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 can be used If the target node is a choice node, the "case" statement can be used
within the "augment" statement. within the "augment" statement.
If the target node is in another module, then nodes added by the If the target node is in another module, then nodes added by the
augmentation MUST NOT be mandatory nodes (see Section 3.1). augmentation MUST NOT be mandatory nodes (see Section 3.1).
The augment statement MUST NOT add multiple nodes with the same name
from the same module to the target node.
7.15.1. The augment's Substatements 7.15.1. The augment's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| case | 7.9.2 | 0..n | | case | 7.9.2 | 0..n |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 | | description | 7.19.3 | 0..1 |
skipping to change at page 94, line 47 skipping to change at page 95, line 31
| uses | 7.12 | 0..n | | uses | 7.12 | 0..n |
| when | 7.19.5 | 0..1 | | when | 7.19.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.15.2. XML Encoding Rules 7.15.2. XML Encoding Rules
All data nodes defined in the "augment" statement are defined as XML All data nodes defined in the "augment" statement are defined as XML
elements in the XML namespace of the module where the "augment" is elements in the XML namespace of the module where the "augment" is
specified. specified.
When a node is augmented, the augmented child nodes are encoded after When a node is augmented, the augmenting child nodes are encoded as
all normal child nodes. If the node is augmented more than once, the subelements to the augmented node, in any order.
blocks of augmented child nodes are sorted (in alphanumeric order)
according to their namespace URI and name of the first child node in
each block.
7.15.3. Usage Example 7.15.3. Usage Example
In namespace http://example.com/schema/interfaces, we have: In namespace http://example.com/schema/interfaces, we have:
container interfaces { container interfaces {
list ifEntry { list ifEntry {
key "ifIndex"; key "ifIndex";
leaf ifIndex { leaf ifIndex {
skipping to change at page 101, line 13 skipping to change at page 102, line 13
abilities and roles. 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
the device does not report that it supports this feature, the local- the device does not report that it supports this feature, the
storage-limit node is not supported. "local-storage-limit" node is not supported.
module syslog { module syslog {
... ...
feature local-storage { feature local-storage {
description description
"This feature means the device supports local "This feature means the device supports local
storage (memory, flash or disk) that can be used to storage (memory, flash or disk) that can be used to
store syslog messages."; store syslog messages.";
} }
skipping to change at page 102, line 22 skipping to change at page 103, line 22
| 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 the name of a feature, as defined by a "feature"
statement. The parent statement is implemented by servers that statement. The parent statement is implemented by servers that
support this feature. If a prefix is present on the feature name, it support this feature. If a prefix is present on the feature name, it
refers to a feature defined the module which was imported with that refers to a feature defined in the module which was imported with
prefix, or the local module if the prefix matches the local module's that prefix, or the local module if the prefix matches the local
prefix. Otherwise a feature with the matching name MUST be defined module's prefix. Otherwise a feature with the matching name MUST be
in the current module or an included submodule. 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 which need to be exposed to submodules MUST be defined in the module which need to be exposed to submodules MUST be defined in
a submodule. Submodules can then include this submodule to find the a submodule. Submodules can then include this submodule to find the
definition of the feature. definition of the feature.
7.18.3. The deviation Statement 7.18.3. The deviation Statement
The deviation statement defines a hierarchy of the module which the The deviation statement defines a hierarchy of the module which the
device does not implement faithfully. The argument is a string that device does not implement faithfully. The argument is a string that
skipping to change at page 105, line 22 skipping to change at page 106, line 22
7.19. Common Statements 7.19. Common Statements
This section defines sub-statements common to several other This section defines sub-statements common to several other
statements. statements.
7.19.1. The config Statement 7.19.1. The config Statement
The "config" statement takes as an argument the string "true" or The "config" statement takes as an argument the string "true" or
"false". If "config" is "true", the definition represents "false". If "config" is "true", the definition represents
configuration. Data nodes representing configuration will be part of configuration. Data nodes representing configuration will be part of
the reply to a <get-config> request, and can be sent in a <copy- the reply to a <get-config> request, and can be sent in a
config> or <edit-config> request. <copy-config> or <edit-config> request.
If "config" is "false", the definition represents state data. Data If "config" is "false", the definition represents state data. Data
nodes representing state data will be part of the reply to a <get>, nodes representing state data will be part of the reply to a <get>,
but not to a <get-config> request. but not to a <get-config> request.
If "config" is not specified, the default is the same as the parent If "config" is not specified, the default is the same as the parent
schema node's "config" value. If the parent node is a "case" node, schema node's "config" value. If the parent node is a "case" node,
the value is the same as the "case" node's parent "choice" node. the value is the same as the "case" node's parent "choice" node.
If the top node does not specify a "config" statement, the default is If the top node does not specify a "config" statement, the default is
skipping to change at page 107, line 50 skipping to change at page 108, line 50
element representing the RPC method being defined as the only element representing the RPC method being defined as the only
child. child.
o If the context node represents RPC output parameters, the tree is o If the context node represents RPC output parameters, the tree is
the RPC reply instance document. The XPath root node has the the RPC reply instance document. The XPath root node has the
elements representing the RPC output parameters as children. elements representing the RPC output parameters as children.
The result of the XPath expression is converted to a boolean value The result of the XPath expression is converted to a boolean value
using the standard XPath rules. using the standard XPath rules.
The XPath expression MUST NOT include any references to the context
node or any descendants of the context node.
Note that the XPath expression is conceptually evaluated. This means Note that the XPath expression is conceptually evaluated. This means
that an implementation does not have to use an XPath evaluator on the that an implementation does not have to use an XPath evaluator on the
device. The augment can very well be implemented with specially device. The augment can very well be implemented with specially
written code. written code.
8. Constraints 8. Constraints
8.1. Constraints on Data 8.1. Constraints on Data
Several YANG statements define constraints on valid data. These Several YANG statements define constraints on valid data. These
skipping to change at page 110, line 15 skipping to change at page 111, line 15
o during parsing of RPC payloads o during parsing of RPC payloads
o during processing of NETCONF operations o during processing of NETCONF operations
o during validation o during validation
Each of these scenarios are considered in the following sections. Each of these scenarios are considered in the following sections.
8.3.1. Payload Parsing 8.3.1. Payload Parsing
When content arrives in RPC payloads, it MUST be well-formed and When content arrives in RPC payloads, it MUST be well-formed XML,
valid XML, following the hierarchy and content rules defined by the following the hierarchy and content rules defined by the set of
set of models the device implements. models the device implements.
o If a leaf data value does not match the type constraints for the o If a leaf data value does not match the type constraints for the
leaf, including those defined in the type's range, length, and leaf, including those defined in the type's range, length, and
pattern properties, the server MUST reply with an 'invalid-value' pattern properties, the server MUST reply with an "invalid-value"
error-tag in the rpc-error, and with the error-app-tag and error- error-tag in the rpc-error, and with the error-app-tag and error-
message assoicated with the constraint, if any exist. message assoicated with the constraint, if any 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 feature is not supported by the device, the server MUST reply with
an 'unknown-element' error-tag in the rpc-error. 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.
o If the attributes "before" and "after" appears in any element that o If the attributes "before" and "after" appears in any element that
is not a list whose "ordered-by" property is "user", the server is not a list whose "ordered-by" property is "user", the server
MUST reply with an 'unkown-attribute' error-tag in the rpc-error. MUST reply with an "unkown-attribute" error-tag in the rpc-error.
8.3.2. NETCONF <edit-config> Processing 8.3.2. NETCONF <edit-config> Processing
After the incoming data is parsed, the NETCONF server performs the After the incoming data is parsed, the NETCONF server performs the
<edit-config> operation by applying the data to the configuration <edit-config> operation by applying the data to the configuration
datastore. During this processing the following errors MUST be datastore. During this processing the following errors MUST be
detected: detected:
o Delete requests for non-existent data. o Delete requests for non-existent data.
skipping to change at page 114, line 20 skipping to change at page 115, line 20
9.2.3. Restrictions 9.2.3. Restrictions
All integer types can be restricted with the "range" statement All integer types can be restricted with the "range" statement
(Section 9.2.4). (Section 9.2.4).
9.2.4. The range Statement 9.2.4. The range Statement
The "range" statement, which is an optional substatement to the The "range" statement, which is an optional substatement to the
"type" statement, takes as an argument a range expression string. It "type" statement, takes as an argument a range expression string. It
is used to restrict integer and floating point built-in types, or is used to restrict integer and decimal built-in types, or types
types derived from those. derived from those.
A range consists of an explicit value, or a lower inclusive bound, A range consists of an explicit value, or a lower inclusive bound,
two consecutive dots "..", and an upper inclusive bound. Multiple two consecutive dots "..", and an upper inclusive bound. Multiple
values or ranges can be given, separated by "|". If multiple values values or ranges can be given, separated by "|". If multiple values
or ranges are given they all MUST be disjoint and MUST be in or ranges are given they all MUST be disjoint and MUST be in
ascending order. If a range restriction is applied to an already ascending order. If a range restriction is applied to an already
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" means the minimum and maximum value accepted "max". "min" and "max" means 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 "range- The range expression syntax is formally defined by the rule
arg" in Section 12. "range-arg" in Section 12.
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 23 skipping to change at page 116, line 23
type my-base-int32-type { type my-base-int32-type {
// legal range restriction // legal range restriction
range "11..max"; // 11..20 range "11..max"; // 11..20
} }
type my-base-int32-type { type my-base-int32-type {
// illegal range restriction // illegal range restriction
range "11..100"; range "11..100";
} }
9.3. The Floating Point Built-in Types 9.3. The decimal64 Built-in Type
The floating point built-in types are float32 and float64. They The decimal64 type represents a subset of the real numbers, which can
represent floating point values of single and double precision as be represented by decimal numerals. The value space of decimal64 is
defined in [IEEE.754]. Special values are positive and negative the set of numbers that can be obtained by multiplying a 64 bit
infinity, and not-a-number. signed integer by a negative power of ten, i.e. expressible as
"i x 10^-n" where i is an integer64 and n is an integer between 1 and
18, inclusively.
9.3.1. Lexicographic Representation 9.3.1. Lexicographic Representation
A floating point value is lexicographically represented as consisting A decimal64 value is lexicographically represented as an optional
of a decimal mantissa followed, optionally, by the character "E" or sign ("+" or "-"), followed by a sequence of decimal digits,
"e", followed by an integer exponent. The special values positive optionally followed by a period ('.') as a decmial indicator and a
and negative infinity and not-a-number have lexical representations sequence of decimal digits. If no sign is specified, "+" is assumed.
INF, -INF and NaN, respectively. The minimal value accepted for a
float is -INF, and the maximal value accepted for a float is INF.
9.3.2. Canonical Form 9.3.2. Canonical Form
[Editor's Note: TBD] The canonical form of a positive decimal64 does not include the sign
"+". The decimal point is required. Leading and trailing zeros are
prohibited, subject to the rule that there MUST be at least one digit
before and after the decimal point. The value zero is represented as
"0.0".
9.3.3. Restrictions 9.3.3. Restrictions
All floating point types can be restricted with the "range" statement A decmial64 type can be restricted with the "range" statement
(Section 9.2.4). (Section 9.2.4).
9.3.4. Usage Example 9.3.4. The fraction-digits Statement
type float32 { The "fraction-digits" statement, which is a substatement to the
range "1..4.5 | 10 | 20..INF"; "type" statement, MUST be present if the type is "decimal64". It
} takes as an argument an integer between 1 and 18, inclusively. It
controls the size of the minimum difference between values of a
decimal64 type, by restricting the value space to numbers that are
expressible as "i x 10^-n" where n is the fraction-digits argument.
is equivalent to 9.3.5. Usage Example
type float32 { type decimal64 {
range "1..4.5 | 10 | 20..max"; fraction-digits 2;
range "1 .. 3.14 | 10 | 20..max";
} }
9.4. The string Built-in Type 9.4. The string Built-in Type
The string built-in type represents human readable strings in YANG. The string built-in type represents human readable strings in YANG.
Legal characters are tab, carriage return, line feed, and the legal Legal characters are tab, carriage return, line feed, and the legal
characters of Unicode and ISO/IEC 10646 [ISO.10646]: characters of Unicode and ISO/IEC 10646 [ISO.10646]:
// any Unicode character, excluding the surrogate blocks, // any Unicode character, excluding the surrogate blocks,
// FFFE, and FFFF. // FFFE, and FFFF.
skipping to change at page 117, line 20 skipping to change at page 118, line 24
is applied to an already length restricted type, the new restriction is applied to an already length restricted type, the new restriction
MUST be equal or more limiting, that is, raising the lower bounds, MUST be equal or more limiting, that is, raising the lower bounds,
reducing the upper bounds, removing explicit length values or ranges, reducing the upper bounds, removing explicit length values or ranges,
or splitting ranges into multiple ranges with intermediate gaps. A or splitting ranges into multiple ranges with intermediate gaps. A
length value is a non-negative integer, or one of the special values length value is a non-negative integer, or one of the special values
"min" or "max". "min" and "max" means the minimum and maximum length "min" or "max". "min" and "max" means the minimum and maximum length
accepted for the type being restricted, respectively. An accepted for the type being restricted, respectively. An
implementation is not required to support a length value larger than implementation is not required to support a length value larger than
18446744073709551615. 18446744073709551615.
The length expression syntax is formally defined by the rule "length- The length expression syntax is formally defined by the rule
arg" in Section 12. "length-arg" in Section 12.
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 |
skipping to change at page 124, line 10 skipping to change at page 125, line 35
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 syntax is formally defined by the rule "path-arg" in Section 12. The syntax is formally defined by the rule "path-arg" in Section 12.
For leafs of type "leafref", the "path" expression evaluates to a For leafs of type "leafref", the "path" expression evaluates to a
node set consisting of zero, one or more nodes. If "require- node set consisting of zero, one or more nodes. If
instance" is "true", the node set MUST be non-empty. "require-instance" is "true", the node set MUST be non-empty.
9.9.3. The require-instance Statement 9.9.3. The require-instance Statement
The "require-instance" statement, which is a substatement to the The "require-instance" statement, which is a substatement to the
"type" statement, MAY be present if the type is "leafref" or "type" statement, MAY be present if the type is "leafref" or
"instance-identifier". It takes as an argument the string "true" or "instance-identifier". It takes as an argument the string "true" or
"false". If this statement is not present, it defaults to "true". "false". If this statement is not present, it defaults to "true".
If "require-instance" is "true", it means that the instance being If "require-instance" is "true", it means that the instance being
referred MUST exist for the data to be valid. This constraint is referred MUST exist for the data to be valid. This constraint is
skipping to change at page 127, line 29 skipping to change at page 128, line 46
9.10.1. Restrictions 9.10.1. Restrictions
An identityref cannot be restricted. An identityref cannot be restricted.
9.10.2. The identityref's base Statement 9.10.2. The identityref's base Statement
The "base" statement, which is a substatement to the "type" The "base" statement, which is a substatement to the "type"
statement, MUST be present if the type is "identityref". The statement, MUST be present if the type is "identityref". The
argument is the name of an identity, as defined by an "identity" argument is the name of an identity, as defined by an "identity"
statement. If a prefix is present on the identity name, it refers to statement. If a prefix is present on the identity name, it refers to
an identity defined the module which was imported with that prefix. an identity defined in the module which was imported with that
Otherwise an identity with the matching name MUST be defined in the prefix. Otherwise an identity with the matching name MUST be defined
current module or an included submodule. in the current module or an included submodule.
Valid values for an identityref are any identities derived from the Valid values for an identityref are any identities derived from the
identityref's base identity. identityref's base identity.
9.10.3. Lexicographic Representation 9.10.3. Lexicographic Representation
An identityref is encoded as the referred identity's Qualified Name An identityref is encoded as the referred identity's Qualified Name
as defined in [XML-NAMES]. If the Prefix is not present, the as defined in [XML-NAMES]. If the Prefix is not present, the
namespace of the identityref is the default namespace in effect on namespace of the identityref is the default namespace in effect on
the element which contains the identityref value. the element which contains the identityref value.
skipping to change at page 128, line 36 skipping to change at page 130, line 4
"des3" identity defined in the "des" module: "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
example encodes the same leaf as above: example encodes the same leaf as above:
<crypto xmlns:x="http://example.com/des">x:des3</crypto> <crypto xmlns:x="http://example.com/des">x:des3</crypto>
If the "crypto" leaf's value instead is "aes" defined in the
If the "crypto" leaf's value instead is "aes" defined in the "my- "my-crypto" module it can be encoded as:
crypto" module it can be encoded as:
<crypto xmlns:mc="http://example.com/my-crypto">mc:aes</crypto> <crypto xmlns:mc="http://example.com/my-crypto">mc:aes</crypto>
or, using the default namespace: or, using the default namespace:
<crypto>aes</crypto> <crypto>aes</crypto>
9.11. The empty Built-in Type 9.11. The empty Built-in Type
The empty built-in type represents a leaf that does not have any The empty built-in type represents a leaf that does not have any
skipping to change at page 129, line 44 skipping to change at page 131, line 11
its member types. its member types.
When the type is "union", the "type" statement (Section 7.4) MUST be When the type is "union", the "type" statement (Section 7.4) MUST be
present. It is used to repeatedly specify each member type of the present. It is used to repeatedly specify each member type of the
union. It takes as an argument a string which is the name of a union. It takes as an argument a string which is the name of a
member type. member type.
A member type can be of any built-in or derived type, except it MUST A member type can be of any built-in or derived type, except it MUST
NOT be one of the built-in types "empty" or "leafref". NOT be one of the built-in types "empty" or "leafref".
When a string representing a union data type is validated, the string
is validated against each member type, in the order they are
specified in the type statement, until a match is found.
Example: Example:
type union { type union {
type int32; type int32;
type enumeration { type enumeration {
enum "unbounded"; enum "unbounded";
} }
} }
9.12.1. Restrictions 9.12.1. Restrictions
skipping to change at page 135, line 32 skipping to change at page 137, line 32
11.1. Formal YIN Definition 11.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 core YANG keywords belong to the YIN elements corresponding to the core YANG keywords belong to the
namespace whose associated URI is namespace whose associated URI is
"urn:ietf:params:xml:ns:yang:yin:1". [XXX IANA]. "urn:ietf:params:xml:ns:yang:yin:1".
YIN elements corresponding to extension keywords belong to the YIN elements corresponding to extension keywords belong to the
namespace of the YANG module where the extension keyword is declared namespace of the YANG module where the extension keyword is declared
via the "extension" statement. via the "extension" statement.
The names of all YIN elements MUST be properly qualified with their The names of all YIN elements MUST be properly qualified with their
namespaces specified above using the standard mechanisms of namespaces specified above using the standard mechanisms of
[XML-NAMES], i.e. "xmlns" and "xmlns:xxx" attributes. [XML-NAMES], i.e. "xmlns" and "xmlns:xxx" attributes.
The argument of a YANG statement is encoded in YIN either as an XML The argument of a YANG statement is encoded in YIN either as an XML
skipping to change at page 136, line 42 skipping to change at page 138, line 42
| container | name | false | | container | name | false |
| default | value | false | | default | value | false |
| description | text | true | | description | text | true |
| deviate | value | false | | deviate | value | false |
| deviation | target-node | false | | deviation | target-node | false |
| enum | name | false | | enum | name | false |
| error-app-tag | value | false | | error-app-tag | value | false |
| error-message | value | true | | error-message | value | true |
| extension | name | false | | extension | name | false |
| feature | name | false | | feature | name | false |
| fraction-digits | value | false |
| grouping | name | false | | grouping | name | false |
| identity | name | false | | identity | name | false |
| if-feature | name | false | | if-feature | name | false |
| import | module | false | | import | module | false |
| include | module | false | | include | module | false |
| input | <no argument> | n/a | | input | <no argument> | n/a |
| key | value | false | | key | value | false |
| leaf | name | false | | leaf | name | false |
| leaf-list | name | false | | leaf-list | name | false |
| length | value | false | | length | value | false |
skipping to change at page 143, line 16 skipping to change at page 145, line 16
[reference-stmt stmtsep] [reference-stmt stmtsep]
"}" "}"
type-stmt = type-keyword sep identifier-ref-arg-str optsep type-stmt = type-keyword sep identifier-ref-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
type-body-stmts type-body-stmts
"}") "}")
type-body-stmts = numerical-restrictions / type-body-stmts = numerical-restrictions /
decimal64-specification /
string-restrictions / string-restrictions /
enum-specification / enum-specification /
leafref-specification / leafref-specification /
identityref-specification / identityref-specification /
instance-identifier-specification / instance-identifier-specification /
bits-specification / bits-specification /
union-specification union-specification
numerical-restrictions = range-stmt stmtsep numerical-restrictions = range-stmt stmtsep
range-stmt = range-keyword sep range-arg-str optsep range-stmt = range-keyword sep range-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[error-message-stmt stmtsep] [error-message-stmt stmtsep]
[error-app-tag-stmt stmtsep] [error-app-tag-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
"}") "}")
decimal64-specification = fraction-digits-stmt
fraction-digits-stmt = fraction-digits-keyword sep
fraction-digits-arg-str stmtend
fraction-digits-arg-str = < a string which matches the rule
fraction-digits-arg >
fraction-digits-arg = ("1" ["2" / "3" / "4" / "5" / "6" / "7" / "8"])
/ "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
string-restrictions = ;; these stmts can appear in any order string-restrictions = ;; these stmts can appear in any order
[length-stmt stmtsep] [length-stmt stmtsep]
*(pattern-stmt stmtsep) *(pattern-stmt stmtsep)
length-stmt = length-keyword sep length-arg-str optsep length-stmt = length-keyword sep length-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[error-message-stmt stmtsep] [error-message-stmt stmtsep]
[error-app-tag-stmt stmtsep] [error-app-tag-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
"}") "}")
skipping to change at page 145, line 21 skipping to change at page 147, line 31
[reference-stmt stmtsep] [reference-stmt stmtsep]
"}" "}"
"}") "}")
position-stmt = position-keyword sep position-stmt = position-keyword sep
position-value-arg-str stmtend position-value-arg-str stmtend
position-value-arg-str = < a string which matches the rule position-value-arg-str = < a string which matches the rule
position-value-arg > position-value-arg >
position-value-arg = non-negative-decimal-value position-value-arg = non-negative-integer-value
status-stmt = status-keyword sep status-arg-str stmtend status-stmt = status-keyword sep status-arg-str stmtend
status-arg-str = < a string which matches the rule status-arg-str = < a string which matches the rule
status-arg > status-arg >
status-arg = current-keyword / status-arg = current-keyword /
obsolete-keyword / obsolete-keyword /
deprecated-keyword deprecated-keyword
skipping to change at page 146, line 29 skipping to change at page 148, line 39
error-message-stmt = error-message-keyword sep string stmtend error-message-stmt = error-message-keyword sep string stmtend
error-app-tag-stmt = error-app-tag-keyword sep string stmtend error-app-tag-stmt = error-app-tag-keyword sep string stmtend
min-elements-stmt = min-elements-keyword sep min-elements-stmt = min-elements-keyword sep
min-value-arg-str stmtend; min-value-arg-str stmtend;
min-value-arg-str = < a string which matches the rule min-value-arg-str = < a string which matches the rule
min-value-arg > min-value-arg >
min-value-arg = non-negative-decimal-value min-value-arg = non-negative-integer-value
max-elements-stmt = max-elements-keyword sep max-elements-stmt = max-elements-keyword sep
max-value-arg-str stmtend; max-value-arg-str stmtend;
max-value-arg-str = < a string which matches the rule max-value-arg-str = < a string which matches the rule
max-value-arg > max-value-arg >
max-value-arg = unbounded-keyword / max-value-arg = unbounded-keyword /
positive-decimal-value positive-integer-value
value-stmt = value-keyword sep decimal-value stmtend
value-stmt = value-keyword sep integer-value stmtend
grouping-stmt = grouping-keyword sep identifier-arg-str optsep grouping-stmt = grouping-keyword sep identifier-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[status-stmt stmtsep] [status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
*((typedef-stmt / *((typedef-stmt /
grouping-stmt) stmtsep) grouping-stmt) stmtsep)
*(data-def-stmt stmtsep) *(data-def-stmt stmtsep)
skipping to change at page 152, line 11 skipping to change at page 154, line 19
[status-stmt stmtsep] [status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
1*((data-def-stmt stmtsep) / 1*((data-def-stmt stmtsep) /
(case-stmt stmtsep)) (case-stmt stmtsep))
"}" "}"
augment-arg-str = < a string which matches the rule augment-arg-str = < a string which matches the rule
augment-arg > augment-arg >
augment-arg = absolute-schema-nodeid augment-arg = schema-nodeid
unknown-statement = prefix ":" identifier [sep string] optsep unknown-statement = prefix ":" identifier [sep string] optsep
(";" / "{" *unknown-statement "}") (";" / "{" *unknown-statement "}")
when-stmt = when-keyword sep string stmtend when-stmt = when-keyword sep string stmtend
rpc-stmt = rpc-keyword sep identifier-arg-str optsep rpc-stmt = rpc-keyword sep identifier-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
skipping to change at page 154, line 34 skipping to change at page 156, line 42
;; Ranges ;; Ranges
range-arg-str = < a string which matches the rule range-arg-str = < a string which matches the rule
range-arg > range-arg >
range-arg = range-part *(optsep "|" optsep range-part) range-arg = range-part *(optsep "|" optsep range-part)
range-part = range-boundary range-part = range-boundary
[optsep ".." optsep range-boundary] [optsep ".." optsep range-boundary]
range-boundary = neginf-keyword / posinf-keyword / range-boundary = min-keyword / max-keyword /
min-keyword / max-keyword / integer-value / decimal-value
decimal-value / float-value
;; Lengths ;; Lengths
length-arg-str = < a string which matches the rule length-arg-str = < a string which matches the rule
length-arg > length-arg >
length-arg = length-part *(optsep "|" optsep length-part) length-arg = length-part *(optsep "|" optsep length-part)
length-part = length-boundary length-part = length-boundary
[optsep ".." optsep length-boundary] [optsep ".." optsep length-boundary]
length-boundary = min-keyword / max-keyword / length-boundary = min-keyword / max-keyword /
non-negative-decimal-value non-negative-integer-value
;; Date ;; Date
date-arg-str = < a string which matches the rule date-arg-str = < a string which matches the rule
date-arg > date-arg >
date-arg = 4DIGIT "-" 2DIGIT "-" 2DIGIT date-arg = 4DIGIT "-" 2DIGIT "-" 2DIGIT
;; Schema Node Identifiers ;; Schema Node Identifiers
schema-nodeid = absolute-schema-nodeid / schema-nodeid = absolute-schema-nodeid /
relative-schema-nodeid descendant-schema-nodeid
absolute-schema-nodeid = 1*("/" node-identifier) absolute-schema-nodeid = 1*("/" node-identifier)
relative-schema-nodeid =
descendant-schema-nodeid /
(("." / "..") "/"
*relative-schema-nodeid)
descendant-schema-nodeid = descendant-schema-nodeid =
node-identifier node-identifier
absolute-schema-nodeid absolute-schema-nodeid
node-identifier = [prefix ":"] identifier node-identifier = [prefix ":"] identifier
;; Instance Identifiers ;; Instance Identifiers
instance-identifier = 1*("/" (node-identifier *predicate)) instance-identifier = 1*("/" (node-identifier *predicate))
predicate = "[" *WSP (predicate-expr / pos) *WSP "]" predicate = "[" *WSP (predicate-expr / pos) *WSP "]"
predicate-expr = (node-identifier / ".") *WSP "=" *WSP predicate-expr = (node-identifier / ".") *WSP "=" *WSP
((DQUOTE string DQUOTE) / ((DQUOTE string DQUOTE) /
(SQUOTE string SQUOTE)) (SQUOTE string SQUOTE))
pos = non-negative-decimal-value) pos = non-negative-integer-value
;; leafref path ;; leafref path
path-arg-str = < a string which matches the rule path-arg-str = < a string which matches the rule
path-arg > path-arg >
path-arg = absolute-path / relative-path path-arg = absolute-path / relative-path
absolute-path = 1*("/" (node-identifier *path-predicate)) absolute-path = 1*("/" (node-identifier *path-predicate))
relative-path = 1*(".." "/") descendant-path relative-path = 1*(".." "/") descendant-path
descendant-path = node-identifier descendant-path = node-identifier
[*path-predicate absolute-path] [*path-predicate absolute-path]
path-predicate = "[" *WSP path-equality-expr *WSP "]" path-predicate = "[" *WSP path-equality-expr *WSP "]"
path-equality-expr = node-identifier *WSP "=" *WSP path-key-expr path-equality-expr = node-identifier *WSP "=" *WSP path-key-expr
path-key-expr = current-function-invocation *WSP "/" *WSP path-key-expr = current-function-invocation *WSP "/" *WSP
rel-path-keyexpr rel-path-keyexpr
skipping to change at page 156, line 41 skipping to change at page 158, line 43
container-keyword = 'container' container-keyword = 'container'
default-keyword = 'default' default-keyword = 'default'
description-keyword = 'description' description-keyword = 'description'
enum-keyword = 'enum' enum-keyword = 'enum'
error-app-tag-keyword = 'error-app-tag' error-app-tag-keyword = 'error-app-tag'
error-message-keyword = 'error-message' error-message-keyword = 'error-message'
extension-keyword = 'extension' extension-keyword = 'extension'
deviation-keyword = 'deviation' deviation-keyword = 'deviation'
deviate-keyword = 'deviate' deviate-keyword = 'deviate'
feature-keyword = 'feature' feature-keyword = 'feature'
fraction-digits-keyword = 'fraction-digits'
grouping-keyword = 'grouping' grouping-keyword = 'grouping'
identity-keyword = 'identity' identity-keyword = 'identity'
if-feature-keyword = 'if-feature' if-feature-keyword = 'if-feature'
import-keyword = 'import' import-keyword = 'import'
include-keyword = 'include' include-keyword = 'include'
input-keyword = 'input' input-keyword = 'input'
key-keyword = 'key' key-keyword = 'key'
leaf-keyword = 'leaf' leaf-keyword = 'leaf'
leaf-list-keyword = 'leaf-list' leaf-list-keyword = 'leaf-list'
length-keyword = 'length' length-keyword = 'length'
skipping to change at page 157, line 47 skipping to change at page 159, line 50
;; 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'
max-keyword = 'max' max-keyword = 'max'
min-keyword = 'min' min-keyword = 'min'
nan-keyword = 'NaN'
neginf-keyword = '-INF'
not-supported-keyword = 'not-supported' not-supported-keyword = 'not-supported'
obsolete-keyword = 'obsolete' obsolete-keyword = 'obsolete'
posinf-keyword = 'INF'
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'
current-function-invocation = current-keyword *WSP "(" *WSP ")" current-function-invocation = current-keyword *WSP "(" *WSP ")"
;; Basic Rules ;; Basic Rules
skipping to change at page 158, line 37 skipping to change at page 160, line 37
*(ALPHA / DIGIT / "_" / "-" / ".") *(ALPHA / DIGIT / "_" / "-" / ".")
identifier-ref-arg-str = < a string which matches the rule identifier-ref-arg-str = < a string which matches the rule
identifier-ref-arg > identifier-ref-arg >
identifier-ref-arg = [prefix ":"] identifier identifier-ref-arg = [prefix ":"] identifier
string = < an unquoted string as returned by string = < an unquoted string as returned by
the scanner > the scanner >
decimal-value = ("-" non-negative-decimal-value) / integer-value = ("-" non-negative-integer-value) /
non-negative-decimal-value non-negative-integer-value
non-negative-decimal-value = "0" / positive-decimal-value non-negative-integer-value = "0" / positive-integer-value
positive-decimal-value = (non-zero-digit *DIGIT) positive-integer-value = (non-zero-digit *DIGIT)
zero-decimal-value = 1*DIGIT zero-integer-value = 1*DIGIT
stmtend = ";" / "{" *unknown-statement "}" stmtend = ";" / "{" *unknown-statement "}"
sep = 1*(WSP / line-break) sep = 1*(WSP / line-break)
; unconditional separator ; unconditional separator
optsep = *(WSP / line-break) optsep = *(WSP / line-break)
stmtsep = *(WSP / line-break / unknown-statement) stmtsep = *(WSP / line-break / unknown-statement)
line-break = CRLF / LF line-break = CRLF / LF
non-zero-digit = %x31-39 non-zero-digit = %x31-39
float-value = neginf-keyword / decimal-value = integer-value ("." zero-integer-value)
posinf-keyword /
nan-keyword /
decimal-value "." zero-decimal-value
*1("E" ("+"/"-") zero-decimal-value)
SQUOTE = %x27 SQUOTE = %x27
; ' (Single Quote) ; ' (Single Quote)
;; ;;
;; RFC 4234 core rules. ;; RFC 4234 core rules.
;; ;;
ALPHA = %x41-5A / %x61-7A ALPHA = %x41-5A / %x61-7A
; A-Z / a-z ; A-Z / a-z
skipping to change at page 161, line 25 skipping to change at page 162, line 25
unique constraint is invalidated, the following error is returned: unique constraint is invalidated, the following error is returned:
Tag: operation-failed Tag: operation-failed
Error-app-tag: data-not-unique Error-app-tag: data-not-unique
Error-info: <non-unique>: Contains an instance identifier which Error-info: <non-unique>: Contains an instance identifier which
points to a leaf which invalidates the unique points to a leaf which invalidates the unique
constraint. This element is present once for each constraint. This element is present once for each
leaf invalidating the unique constraint. leaf invalidating the unique constraint.
The <non-unique> element is in the YANG The <non-unique> element is in the YANG
namespace ("urn:ietf:params:xml:ns:yang:1" namespace ("urn:ietf:params:xml:ns:yang:1").
[XXX IANA]).
13.2. Error Message for Data that Violates a max-elements Statement: 13.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:
Tag: operation-failed Tag: operation-failed
Error-app-tag: too-many-elements Error-app-tag: too-many-elements
skipping to change at page 162, line 40 skipping to change at page 163, line 40
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:
Tag: data-missing 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").
[XXX IANA]).
13.7. Error Message for the "insert" Operation 13.7. Error Message for the "insert" Operation
If the "insert" and "key" or "value" attributes are used in an <edit- If the "insert" and "key" or "value" attributes are used in an
config> for a list or leaf-list node, and the "key" or "value" refers <edit-config> for a list or leaf-list node, and the "key" or "value"
to a non-existing instance, the following error is returned: refers to a non-existing instance, the following error is returned:
Tag: bad-attribute Tag: bad-attribute
Error-app-tag: missing-instance Error-app-tag: missing-instance
14. IANA Considerations 14. IANA Considerations
+-------------------------------------------------------------------+ This document defines a registry for YANG module and submodule names.
| Open Question | The name of the registry is "YANG Module Names".
+-------------------------------------------------------------------+
| Write this section properly. We need a registry for (sub)module |
| names and module namespaces. |
+-------------------------------------------------------------------+
This document registers two URIs for the YANG XML namespace in the The registry shall record for each entry:
IETF XML registry [RFC3688].
URI: urn:ietf:params:xml:ns:yang:yin:1 o the name of the module or submodule
o for modules, the assigned XML namespace
o for submodules, the name of the module it belongs to
o a reference to the (sub)module's documentation (the RFC number)
For allocation, RFC publication is required as per RFC 5226
[RFC5226]. All registered YANG module names must comply with the
rules for identifiers stated in Section 6.2. There are no initial
assignments.
The module name prefix 'ietf-' is reserved for IETF stream documents
while the module name prefix 'irtf-' is reserved for IRTF stream
documents. Modules published in other RFC streams must have a
similar suitable prefix. The prefix 'iana-' is reserved for modules
maintained by IANA.
This document registers two URIs for the YANG and YIN XML namespaces
in the IETF XML registry [RFC3688]. Following the format in RFC
3688, the following registration is requested.
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.
XML: N/A, the requested URIs are XML namespaces.
15. Security Considerations 15. Security Considerations
This document defines a language with which to write and read This document defines a language with which to write and read
descriptions of management information. The language itself has no descriptions of management information. The language itself has no
security impact on the Internet. security impact on the Internet.
Data modeled in YANG might contain sensitive information. RPCs or Data modeled in YANG might contain sensitive information. RPCs or
notifications defined in YANG might transfer sensitive information. notifications defined in YANG might transfer sensitive information.
Security issues are related to the usage of data modeled in YANG. Security issues are related to the usage of data modeled in YANG.
skipping to change at page 166, line 5 skipping to change at page 167, line 5
The following people all contributed significantly to the initial The following people all contributed significantly to the initial
YANG draft: YANG draft:
- Andy Bierman (andybierman.com) - Andy Bierman (andybierman.com)
- 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. References 17. Acknowledgements
17.1. Normative References The editor wishes to thank the following individuals, who all
provided helpful comments on various versions of this document:
Mehmet Ersue, Washam Fan, Joel Halpern, Leif Johansson, Ladislav
Lhotka, Gerhard Muenz, Tom Petch, Randy Preshun, David Reid, and Bert
Wijnen.
[IEEE.754] 18. References
Institute of Electrical and Electronics Engineers,
"Standard for Binary Floating-Point Arithmetic", 18.1. Normative References
IEEE Standard 754, August 1985.
[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) - Part 1: Architecture and Basic Character Set (UCS) - Part 1: Architecture and Basic
Multilingual Plane", ISO Standard 10646-1, May 1993. Multilingual Plane", ISO Standard 10646-1, May 1993.
[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.
skipping to change at page 166, line 39 skipping to change at page 168, line 34
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006. December 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, July 2008. Notifications", RFC 5277, July 2008.
[XML-NAMES] [XML-NAMES]
Tobin, R., Bray, T., Hollander, D., and A. Layman, Tobin, R., Bray, T., Hollander, D., and A. Layman,
"Namespaces in XML 1.0 (Second Edition)", World Wide Web "Namespaces in XML 1.0 (Second Edition)", World Wide Web
Consortium Recommendation REC-xml-names-20060816, Consortium Recommendation REC-xml-names-20060816,
skipping to change at page 167, line 18 skipping to change at page 169, line 17
[XSD-TYPES] [XSD-TYPES]
Biron, P V. and A. Malhotra, "XML Schema Part 2: Datatypes Biron, P V. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", W3C REC REC-xmlschema-2-20041028, Second Edition", W3C REC REC-xmlschema-2-20041028,
October 2004. October 2004.
[XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World [XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World
Wide Web Consortium Recommendation REC-xslt-19991116, Wide Web Consortium Recommendation REC-xslt-19991116,
November 1999, November 1999,
<http://www.w3.org/TR/1999/REC-xslt-19991116>. <http://www.w3.org/TR/1999/REC-xslt-19991116>.
17.2. Non-Normative References 18.2. Non-Normative 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", Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, April 1999. STD 58, RFC 2579, April 1999.
[RFC3780] Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation [RFC3780] Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation
Structure of Management Information", RFC 3780, May 2004. Structure of Management Information", RFC 3780, May 2004.
Appendix A. ChangeLog Appendix A. ChangeLog
A.1. Version -04 A.1. Version -05
o Replaced the data types "float32" and "float64" with "decimal64".
o Specified that the elements in the XML encoding of configuration
data can occur in any order.
o Clarified that "augment" cannot add multiple nodes with the same
name.
o Clarified what "when" means in RPC input / output.
o Wrote the IANA Considerations section.
o Changed requirement for minimum identifier length to 64
characters.
A.2. Version -04
o Using "revision-date" substatement to "import" and "include". o Using "revision-date" substatement to "import" and "include".
o Corrected grammar and text for instance-identifier. o Corrected grammar and text for instance-identifier.
o Fixed bugs in some examples. o Fixed bugs in some examples.
o Rewrote the YIN description to use a declarative style. o Rewrote the YIN description to use a declarative style.
o Added two error codes in Section 13. o Added two error codes in Section 13.
skipping to change at page 168, line 33 skipping to change at page 171, line 5
o Corrected grammar for key-arg; now allowing optional prefix on o Corrected grammar for key-arg; now allowing optional prefix on
each leaf identifier. each leaf identifier.
o Clarified that "unique" constraints only check instances with o Clarified that "unique" constraints only check instances with
values for all referenced leafs. values for all referenced leafs.
o Clarified how mandatory and min-elements constraints are enforced. o Clarified how mandatory and min-elements constraints are enforced.
o Editorial fixes. o Editorial fixes.
A.2. Version -03 A.3. Version -03
o Added import by revision (yang-00413) o Added import by revision (yang-00413)
o Changed type "keyref" to "leafref", and added the statement o Changed type "keyref" to "leafref", and added the statement
"require-instance" (yang-01253) "require-instance" (yang-01253)
o Clarified that data sent from the server must be in the canonical o Clarified that data sent from the server must be in the canonical
form. form.
o Clarified when and how constraints in the models are enforced. o Clarified when and how constraints in the models are enforced.
o Many editorial fixes o Many editorial fixes
o Added more strict grammar for the "deviate" statement. o Added more strict grammar for the "deviate" statement.
A.3. Version -02 A.4. Version -02
o Added module update rules. (yang-00000) o Added module update rules. (yang-00000)
o Added "refine" statement as a substatement to "uses". (yang-00088) o Added "refine" statement as a substatement to "uses". (yang-00088)
o Allow "augment" on top-level and in "uses" only. (yang-00088) o Allow "augment" on top-level and in "uses" only. (yang-00088)
o Allow "when" on all data defintion statements. (yang-00088) o Allow "when" on all data defintion statements. (yang-00088)
o Added section "Constraints" and clarified when constraints are o Added section "Constraints" and clarified when constraints are
skipping to change at page 169, line 30 skipping to change at page 171, line 46
o Added "prefix" as a substatement to "belongs-to". (yang-00755) o Added "prefix" as a substatement to "belongs-to". (yang-00755)
o Added section on Conformance. (yang-01281) o Added section on Conformance. (yang-01281)
o Added "deviation" statement. (yang-01281) o Added "deviation" statement. (yang-01281)
o Added "identity" statement and "identityref" type. (yang-01339) o Added "identity" statement and "identityref" type. (yang-01339)
o Aligned grammar for "enum" with text. o Aligned grammar for "enum" with text.
A.4. Version -01 A.5. Version -01
o Removed "Appendix A. Derived YANG Types". o Removed "Appendix A. Derived YANG Types".
o Removed "Appendix C. XML Schema Considerations". o Removed "Appendix C. XML Schema Considerations".
o Removed "Appendix F. Why We Need a New Modeling Language". o Removed "Appendix F. Why We Need a New Modeling Language".
o Moved "Appendix B. YIN" to its own section. o Moved "Appendix B. YIN" to its own section.
o Moved "Appendix D. YANG ABNF Grammar" to its own section. o Moved "Appendix D. YANG ABNF Grammar" to its own section.
skipping to change at page 170, line 27 skipping to change at page 172, line 44
o Fixed whitespace issues in the ABNF grammar. o Fixed whitespace issues in the ABNF grammar.
o Added the term "mandatory node", and refer to it in the o Added the term "mandatory node", and refer to it in the
description of augment (see Section 7.15), and choice (see description of augment (see Section 7.15), and choice (see
Section 7.9.3). Section 7.9.3).
o Added support for multiple "pattern" statements in "type". o Added support for multiple "pattern" statements in "type".
o Several clarifications and fixed typos. o Several clarifications and fixed typos.
A.5. Version -00 A.6. Version -00
Changes from draft-bjorklund-netconf-yang-02.txt Changes from draft-bjorklund-netconf-yang-02.txt
o Fixed bug in grammar for bit-stmt o Fixed bug in grammar for bit-stmt
o Fixed bugs in example XPath expressions o Fixed bugs in example XPath expressions
o Added keyword 'presence' to the YIN mapping table o Added keyword 'presence' to the YIN mapping table
Author's Address Author's Address
Martin Bjorklund (editor) Martin Bjorklund (editor)
Tail-f Systems Tail-f Systems
Email: mbj@tail-f.com Email: mbj@tail-f.com
 End of changes. 112 change blocks. 
295 lines changed or deleted 359 lines changed or added

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