draft-ietf-netmod-yang-09.txt   draft-ietf-netmod-yang-10.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 December 1, 2009 Intended status: Standards Track January 12, 2010
Expires: June 4, 2010 Expires: July 16, 2010
YANG - A data modeling language for NETCONF YANG - A data modeling language for NETCONF
draft-ietf-netmod-yang-09 draft-ietf-netmod-yang-10
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 June 4, 2010. This Internet-Draft will expire on July 16, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
skipping to change at page 3, line 51 skipping to change at page 3, line 51
7.5.5. The presence Statement . . . . . . . . . . . . . . . 58 7.5.5. The presence Statement . . . . . . . . . . . . . . . 58
7.5.6. The container's Child Node Statements . . . . . . . . 58 7.5.6. The container's Child Node Statements . . . . . . . . 58
7.5.7. XML Mapping Rules . . . . . . . . . . . . . . . . . . 58 7.5.7. XML Mapping Rules . . . . . . . . . . . . . . . . . . 58
7.5.8. NETCONF <edit-config> Operations . . . . . . . . . . 58 7.5.8. NETCONF <edit-config> Operations . . . . . . . . . . 58
7.5.9. Usage Example . . . . . . . . . . . . . . . . . . . . 59 7.5.9. Usage Example . . . . . . . . . . . . . . . . . . . . 59
7.6. The leaf Statement . . . . . . . . . . . . . . . . . . . 60 7.6. The leaf Statement . . . . . . . . . . . . . . . . . . . 60
7.6.1. The leaf's default value . . . . . . . . . . . . . . 60 7.6.1. The leaf's default value . . . . . . . . . . . . . . 60
7.6.2. The leaf's Substatements . . . . . . . . . . . . . . 61 7.6.2. The leaf's Substatements . . . . . . . . . . . . . . 61
7.6.3. The leaf's type Statement . . . . . . . . . . . . . . 61 7.6.3. The leaf's type Statement . . . . . . . . . . . . . . 61
7.6.4. The leaf's default Statement . . . . . . . . . . . . 61 7.6.4. The leaf's default Statement . . . . . . . . . . . . 61
7.6.5. The leaf's mandatory Statement . . . . . . . . . . . 61 7.6.5. The leaf's mandatory Statement . . . . . . . . . . . 62
7.6.6. XML Mapping Rules . . . . . . . . . . . . . . . . . . 62 7.6.6. XML Mapping Rules . . . . . . . . . . . . . . . . . . 62
7.6.7. NETCONF <edit-config> Operations . . . . . . . . . . 62 7.6.7. NETCONF <edit-config> Operations . . . . . . . . . . 62
7.6.8. Usage Example . . . . . . . . . . . . . . . . . . . . 63 7.6.8. Usage Example . . . . . . . . . . . . . . . . . . . . 63
7.7. The leaf-list Statement . . . . . . . . . . . . . . . . . 63 7.7. The leaf-list Statement . . . . . . . . . . . . . . . . . 64
7.7.1. Ordering . . . . . . . . . . . . . . . . . . . . . . 64 7.7.1. Ordering . . . . . . . . . . . . . . . . . . . . . . 64
7.7.2. The leaf-list's Substatements . . . . . . . . . . . . 65 7.7.2. The leaf-list's Substatements . . . . . . . . . . . . 65
7.7.3. The min-elements Statement . . . . . . . . . . . . . 65 7.7.3. The min-elements Statement . . . . . . . . . . . . . 65
7.7.4. The max-elements Statement . . . . . . . . . . . . . 65 7.7.4. The max-elements Statement . . . . . . . . . . . . . 65
7.7.5. The ordered-by Statement . . . . . . . . . . . . . . 66 7.7.5. The ordered-by Statement . . . . . . . . . . . . . . 66
7.7.6. XML Mapping Rules . . . . . . . . . . . . . . . . . . 66 7.7.6. XML Mapping Rules . . . . . . . . . . . . . . . . . . 66
7.7.7. NETCONF <edit-config> operations . . . . . . . . . . 67 7.7.7. NETCONF <edit-config> Operations . . . . . . . . . . 67
7.7.8. Usage Example . . . . . . . . . . . . . . . . . . . . 68 7.7.8. Usage Example . . . . . . . . . . . . . . . . . . . . 68
7.8. The list Statement . . . . . . . . . . . . . . . . . . . 69 7.8. The list Statement . . . . . . . . . . . . . . . . . . . 69
7.8.1. The list's Substatements . . . . . . . . . . . . . . 70 7.8.1. The list's Substatements . . . . . . . . . . . . . . 70
7.8.2. The list's key Statement . . . . . . . . . . . . . . 70 7.8.2. The list's key Statement . . . . . . . . . . . . . . 70
7.8.3. The list's unique Statement . . . . . . . . . . . . . 71 7.8.3. The list's unique Statement . . . . . . . . . . . . . 71
7.8.4. The list's Child Node Statements . . . . . . . . . . 72 7.8.4. The list's Child Node Statements . . . . . . . . . . 72
7.8.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 72 7.8.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 72
7.8.6. NETCONF <edit-config> operations . . . . . . . . . . 73 7.8.6. NETCONF <edit-config> Operations . . . . . . . . . . 73
7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 73 7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 74
7.9. The choice Statement . . . . . . . . . . . . . . . . . . 77 7.9. The choice Statement . . . . . . . . . . . . . . . . . . 77
7.9.1. The choice's Substatements . . . . . . . . . . . . . 77 7.9.1. The choice's Substatements . . . . . . . . . . . . . 78
7.9.2. The choice's case Statement . . . . . . . . . . . . . 77 7.9.2. The choice's case Statement . . . . . . . . . . . . . 78
7.9.3. The choice's default Statement . . . . . . . . . . . 79 7.9.3. The choice's default Statement . . . . . . . . . . . 79
7.9.4. The choice's mandatory Statement . . . . . . . . . . 80 7.9.4. The choice's mandatory Statement . . . . . . . . . . 81
7.9.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 81 7.9.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 81
7.9.6. NETCONF <edit-config> operations . . . . . . . . . . 81 7.9.6. NETCONF <edit-config> Operations . . . . . . . . . . 81
7.9.7. Usage Example . . . . . . . . . . . . . . . . . . . . 81 7.9.7. Usage Example . . . . . . . . . . . . . . . . . . . . 81
7.10. The anyxml Statement . . . . . . . . . . . . . . . . . . 82 7.10. The anyxml Statement . . . . . . . . . . . . . . . . . . 82
7.10.1. The anyxml's Substatements . . . . . . . . . . . . . 83 7.10.1. The anyxml's Substatements . . . . . . . . . . . . . 83
7.10.2. XML Mapping Rules . . . . . . . . . . . . . . . . . . 83 7.10.2. XML Mapping Rules . . . . . . . . . . . . . . . . . . 83
7.10.3. NETCONF <edit-config> operations . . . . . . . . . . 83 7.10.3. NETCONF <edit-config> Operations . . . . . . . . . . 83
7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . . 84 7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . . 84
7.11. The grouping Statement . . . . . . . . . . . . . . . . . 84 7.11. The grouping Statement . . . . . . . . . . . . . . . . . 84
7.11.1. The grouping's Substatements . . . . . . . . . . . . 85 7.11.1. The grouping's Substatements . . . . . . . . . . . . 85
7.11.2. Usage Example . . . . . . . . . . . . . . . . . . . . 85 7.11.2. Usage Example . . . . . . . . . . . . . . . . . . . . 86
7.12. The uses Statement . . . . . . . . . . . . . . . . . . . 85 7.12. The uses Statement . . . . . . . . . . . . . . . . . . . 86
7.12.1. The uses's Substatements . . . . . . . . . . . . . . 86 7.12.1. The uses's Substatements . . . . . . . . . . . . . . 87
7.12.2. The refine Statement . . . . . . . . . . . . . . . . 86 7.12.2. The refine Statement . . . . . . . . . . . . . . . . 87
7.12.3. XML Mapping Rules . . . . . . . . . . . . . . . . . . 87 7.12.3. XML Mapping Rules . . . . . . . . . . . . . . . . . . 88
7.12.4. Usage Example . . . . . . . . . . . . . . . . . . . . 87 7.12.4. Usage Example . . . . . . . . . . . . . . . . . . . . 88
7.13. The rpc Statement . . . . . . . . . . . . . . . . . . . . 88 7.13. The rpc Statement . . . . . . . . . . . . . . . . . . . . 89
7.13.1. The rpc's Substatements . . . . . . . . . . . . . . . 89 7.13.1. The rpc's Substatements . . . . . . . . . . . . . . . 90
7.13.2. The input Statement . . . . . . . . . . . . . . . . . 89 7.13.2. The input Statement . . . . . . . . . . . . . . . . . 90
7.13.3. The output Statement . . . . . . . . . . . . . . . . 90 7.13.3. The output Statement . . . . . . . . . . . . . . . . 91
7.13.4. XML Mapping Rules . . . . . . . . . . . . . . . . . . 91 7.13.4. XML Mapping Rules . . . . . . . . . . . . . . . . . . 92
7.13.5. Usage Example . . . . . . . . . . . . . . . . . . . . 91 7.13.5. Usage Example . . . . . . . . . . . . . . . . . . . . 92
7.14. The notification Statement . . . . . . . . . . . . . . . 92 7.14. The notification Statement . . . . . . . . . . . . . . . 93
7.14.1. The notification's Substatements . . . . . . . . . . 93 7.14.1. The notification's Substatements . . . . . . . . . . 94
7.14.2. XML Mapping Rules . . . . . . . . . . . . . . . . . . 93 7.14.2. XML Mapping Rules . . . . . . . . . . . . . . . . . . 94
7.14.3. Usage Example . . . . . . . . . . . . . . . . . . . . 93 7.14.3. Usage Example . . . . . . . . . . . . . . . . . . . . 94
7.15. The augment Statement . . . . . . . . . . . . . . . . . . 94 7.15. The augment Statement . . . . . . . . . . . . . . . . . . 95
7.15.1. The augment's Substatements . . . . . . . . . . . . . 95 7.15.1. The augment's Substatements . . . . . . . . . . . . . 96
7.15.2. XML Mapping Rules . . . . . . . . . . . . . . . . . . 95 7.15.2. XML Mapping Rules . . . . . . . . . . . . . . . . . . 96
7.15.3. Usage Example . . . . . . . . . . . . . . . . . . . . 95 7.15.3. Usage Example . . . . . . . . . . . . . . . . . . . . 96
7.16. The identity Statement . . . . . . . . . . . . . . . . . 97 7.16. The identity Statement . . . . . . . . . . . . . . . . . 98
7.16.1. The identity's Substatements . . . . . . . . . . . . 98 7.16.1. The identity's Substatements . . . . . . . . . . . . 99
7.16.2. The base Statement . . . . . . . . . . . . . . . . . 98 7.16.2. The base Statement . . . . . . . . . . . . . . . . . 99
7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . . 99 7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . . 100
7.17. The extension Statement . . . . . . . . . . . . . . . . . 99 7.17. The extension Statement . . . . . . . . . . . . . . . . . 100
7.17.1. The extension's Substatements . . . . . . . . . . . . 100 7.17.1. The extension's Substatements . . . . . . . . . . . . 101
7.17.2. The argument Statement . . . . . . . . . . . . . . . 100 7.17.2. The argument Statement . . . . . . . . . . . . . . . 101
7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . . 101 7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . . 102
7.18. Conformance-related Statements . . . . . . . . . . . . . 101 7.18. Conformance-related Statements . . . . . . . . . . . . . 102
7.18.1. The feature Statement . . . . . . . . . . . . . . . . 101 7.18.1. The feature Statement . . . . . . . . . . . . . . . . 102
7.18.2. The if-feature Statement . . . . . . . . . . . . . . 103 7.18.2. The if-feature Statement . . . . . . . . . . . . . . 104
7.18.3. The deviation Statement . . . . . . . . . . . . . . . 103 7.18.3. The deviation Statement . . . . . . . . . . . . . . . 104
7.19. Common Statements . . . . . . . . . . . . . . . . . . . . 106 7.19. Common Statements . . . . . . . . . . . . . . . . . . . . 107
7.19.1. The config Statement . . . . . . . . . . . . . . . . 106 7.19.1. The config Statement . . . . . . . . . . . . . . . . 107
7.19.2. The status Statement . . . . . . . . . . . . . . . . 106 7.19.2. The status Statement . . . . . . . . . . . . . . . . 107
7.19.3. The description Statement . . . . . . . . . . . . . . 107 7.19.3. The description Statement . . . . . . . . . . . . . . 108
7.19.4. The reference Statement . . . . . . . . . . . . . . . 107 7.19.4. The reference Statement . . . . . . . . . . . . . . . 108
7.19.5. The when Statement . . . . . . . . . . . . . . . . . 107 7.19.5. The when Statement . . . . . . . . . . . . . . . . . 108
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 decimal64 Built-in Type . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 116 9.3.3. Restrictions . . . . . . . . . . . . . . . . . . . . 117
9.3.4. The fraction-digits Statement . . . . . . . . . . . . 116 9.3.4. The fraction-digits Statement . . . . . . . . . . . . 117
9.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 116 9.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 118
9.4. The string Built-in Type . . . . . . . . . . . . . . . . 117 9.4. The string Built-in Type . . . . . . . . . . . . . . . . 118
9.4.1. Lexicographic Representation . . . . . . . . . . . . 117 9.4.1. Lexicographic Representation . . . . . . . . . . . . 118
9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 117 9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 118
9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 117 9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 118
9.4.4. The length Statement . . . . . . . . . . . . . . . . 117 9.4.4. The length Statement . . . . . . . . . . . . . . . . 118
9.4.5. Usage Example . . . . . . . . . . . . . . . . . . . . 118 9.4.5. Usage Example . . . . . . . . . . . . . . . . . . . . 119
9.4.6. The pattern Statement . . . . . . . . . . . . . . . . 118 9.4.6. The pattern Statement . . . . . . . . . . . . . . . . 120
9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 119 9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 120
9.5. The boolean Built-in Type . . . . . . . . . . . . . . . . 119 9.5. The boolean Built-in Type . . . . . . . . . . . . . . . . 121
9.5.1. Lexicographic Representation . . . . . . . . . . . . 119 9.5.1. Lexicographic Representation . . . . . . . . . . . . 121
9.5.2. Canonical Form . . . . . . . . . . . . . . . . . . . 119 9.5.2. Canonical Form . . . . . . . . . . . . . . . . . . . 121
9.5.3. Restrictions . . . . . . . . . . . . . . . . . . . . 120 9.5.3. Restrictions . . . . . . . . . . . . . . . . . . . . 121
9.6. The enumeration Built-in Type . . . . . . . . . . . . . . 120 9.6. The enumeration Built-in Type . . . . . . . . . . . . . . 121
9.6.1. Lexicographic Representation . . . . . . . . . . . . 120 9.6.1. Lexicographic Representation . . . . . . . . . . . . 121
9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 120 9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 121
9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 120 9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 121
9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 120 9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 121
9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 121 9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 122
9.7. The bits Built-in Type . . . . . . . . . . . . . . . . . 122 9.7. The bits Built-in Type . . . . . . . . . . . . . . . . . 123
9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 122 9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 123
9.7.2. Lexicographic Representation . . . . . . . . . . . . 122 9.7.2. Lexicographic Representation . . . . . . . . . . . . 123
9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 122 9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 123
9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 122 9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 123
9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 123 9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 124
9.8. The binary Built-in Type . . . . . . . . . . . . . . . . 124 9.8. The binary Built-in Type . . . . . . . . . . . . . . . . 124
9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 124 9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 125
9.8.2. Lexicographic Representation . . . . . . . . . . . . 124 9.8.2. Lexicographic Representation . . . . . . . . . . . . 125
9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 124 9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 125
9.9. The leafref Built-in Type . . . . . . . . . . . . . . . . 124 9.9. The leafref Built-in Type . . . . . . . . . . . . . . . . 125
9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 125 9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 125
9.9.2. The path Statement . . . . . . . . . . . . . . . . . 125 9.9.2. The path Statement . . . . . . . . . . . . . . . . . 125
9.9.3. Lexicographic Representation . . . . . . . . . . . . 126 9.9.3. Lexicographic Representation . . . . . . . . . . . . 126
9.9.4. Canonical Form . . . . . . . . . . . . . . . . . . . 126 9.9.4. Canonical Form . . . . . . . . . . . . . . . . . . . 126
9.9.5. Usage Example . . . . . . . . . . . . . . . . . . . . 126 9.9.5. Usage Example . . . . . . . . . . . . . . . . . . . . 126
9.10. The identityref Built-in Type . . . . . . . . . . . . . . 129 9.10. The identityref Built-in Type . . . . . . . . . . . . . . 130
9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 129 9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 130
9.10.2. The identityref's base Statement . . . . . . . . . . 129 9.10.2. The identityref's base Statement . . . . . . . . . . 130
9.10.3. Lexicographic Representation . . . . . . . . . . . . 130 9.10.3. Lexicographic Representation . . . . . . . . . . . . 131
9.10.4. Canonical Form . . . . . . . . . . . . . . . . . . . 130 9.10.4. Canonical Form . . . . . . . . . . . . . . . . . . . 131
9.10.5. Usage Example . . . . . . . . . . . . . . . . . . . . 130 9.10.5. Usage Example . . . . . . . . . . . . . . . . . . . . 131
9.11. The empty Built-in Type . . . . . . . . . . . . . . . . . 131 9.11. The empty Built-in Type . . . . . . . . . . . . . . . . . 132
9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 131 9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 132
9.11.2. Lexicographic Representation . . . . . . . . . . . . 131 9.11.2. Lexicographic Representation . . . . . . . . . . . . 132
9.11.3. Canonical Form . . . . . . . . . . . . . . . . . . . 131 9.11.3. Canonical Form . . . . . . . . . . . . . . . . . . . 132
9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . . 131 9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . . 132
9.12. The union Built-in Type . . . . . . . . . . . . . . . . . 132 9.12. The union Built-in Type . . . . . . . . . . . . . . . . . 133
9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 132 9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 133
9.12.2. Lexicographic Representation . . . . . . . . . . . . 132 9.12.2. Lexicographic Representation . . . . . . . . . . . . 133
9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 132 9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 133
9.13. The instance-identifier Built-in Type . . . . . . . . . . 133 9.13. The instance-identifier Built-in Type . . . . . . . . . . 134
9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 133 9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 134
9.13.2. The require-instance Statement . . . . . . . . . . . 134 9.13.2. The require-instance Statement . . . . . . . . . . . 135
9.13.3. Lexicographic Representation . . . . . . . . . . . . 134 9.13.3. Lexicographic Representation . . . . . . . . . . . . 135
9.13.4. Canonical Form . . . . . . . . . . . . . . . . . . . 134 9.13.4. Canonical Form . . . . . . . . . . . . . . . . . . . 135
9.13.5. Usage Example . . . . . . . . . . . . . . . . . . . . 134 9.13.5. Usage Example . . . . . . . . . . . . . . . . . . . . 135
10. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 136 10. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 137
11. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 11. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
11.1. Formal YIN Definition . . . . . . . . . . . . . . . . . . 139 11.1. Formal YIN Definition . . . . . . . . . . . . . . . . . . 140
11.1.1. Usage Example . . . . . . . . . . . . . . . . . . . . 141 11.1.1. Usage Example . . . . . . . . . . . . . . . . . . . . 142
12. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 143 12. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 145
13. Error Responses for YANG Related Errors . . . . . . . . . . . 165 13. Error Responses for YANG Related Errors . . . . . . . . . . . 167
13.1. Error Message for Data that Violates a unique Statement . 165 13.1. Error Message for Data that Violates a unique Statement . 167
13.2. Error Message for Data that Violates a max-elements 13.2. Error Message for Data that Violates a max-elements
Statement . . . . . . . . . . . . . . . . . . . . . . . . 165 Statement . . . . . . . . . . . . . . . . . . . . . . . . 167
13.3. Error Message for Data that Violates a min-elements 13.3. Error Message for Data that Violates a min-elements
Statement . . . . . . . . . . . . . . . . . . . . . . . . 165 Statement . . . . . . . . . . . . . . . . . . . . . . . . 167
13.4. Error Message for Data that Violates a must Statement . . 166 13.4. Error Message for Data that Violates a must Statement . . 168
13.5. Error Message for Data that Violates a 13.5. Error Message for Data that Violates a
require-instance Statement . . . . . . . . . . . . . . . 166 require-instance Statement . . . . . . . . . . . . . . . 168
13.6. Error Message for Data that does not Match a leafref 13.6. Error Message for Data that does not Match a leafref
Type . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Type . . . . . . . . . . . . . . . . . . . . . . . . . . 168
13.7. Error Message for Data that Violates a mandatory 13.7. Error Message for Data that Violates a mandatory
choice Statement . . . . . . . . . . . . . . . . . . . . 166 choice Statement . . . . . . . . . . . . . . . . . . . . 168
13.8. Error Message for the "insert" Operation . . . . . . . . 167 13.8. Error Message for the "insert" Operation . . . . . . . . 169
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 168 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 170
15. Security Considerations . . . . . . . . . . . . . . . . . . . 169 15. Security Considerations . . . . . . . . . . . . . . . . . . . 171
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 170 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 172
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 171 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 173
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 172 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 174
18.1. Normative References . . . . . . . . . . . . . . . . . . 172 18.1. Normative References . . . . . . . . . . . . . . . . . . 174
18.2. Non-Normative References . . . . . . . . . . . . . . . . 173 18.2. Non-Normative References . . . . . . . . . . . . . . . . 175
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 174 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 176
A.1. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 174 A.1. Version -10 . . . . . . . . . . . . . . . . . . . . . . . 176
A.2. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 174 A.2. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 176
A.3. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 174 A.3. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 176
A.4. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 175 A.4. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 177
A.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 175 A.5. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 177
A.6. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 175 A.6. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 177
A.7. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 176 A.7. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 178
A.8. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 176 A.8. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 178
A.9. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 177 A.9. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 178
A.10. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 178 A.10. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 179
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 179 A.11. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 180
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 181
1. Introduction 1. Introduction
YANG is a data modeling language used to model configuration and YANG is a data modeling language used to model configuration and
state data manipulated by the Network Configuration Protocol state data manipulated by the Network Configuration Protocol
(NETCONF) protocol, NETCONF remote procedure calls, and NETCONF (NETCONF) protocol, NETCONF remote procedure calls, and NETCONF
notifications. YANG is used to model the operations and content notifications. YANG is used to model the operations and content
layers of NETCONF (see the NETCONF Configuration Protocol [RFC4741], layers of NETCONF (see the NETCONF Configuration Protocol [RFC4741],
section 1.1). section 1.1).
skipping to change at page 10, line 7 skipping to change at page 10, line 7
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
o anyxml: A node which can contain an unknown chunk of XML data. o anyxml: A data node which can contain an unknown chunk of XML
data.
o augment: Adds new nodes to a previously defined node. o augment: Adds new schema nodes to a previously defined schema
node.
o base type: The type from which a derived type was derived, which o base type: The type from which a derived type was derived, which
may be either a built-in type or another derived type. may be either a built-in type or another derived type.
o built-in type: A YANG data type defined in the YANG language, such o built-in type: A YANG data type defined in the YANG language, such
as uint32 or string. as uint32 or string.
o choice: A node where only one of a number of identified o choice: A schema node where only one of a number of identified
alternative nodes is valid. alternatives is valid.
o configuration data: The set of writable data that is required to o configuration data: The set of writable data that is required to
transform a system from its initial default state into its current transform a system from its initial default state into its current
state [RFC4741]. state [RFC4741].
o conformance: A measure of how accurately a device follows the o conformance: A measure of how accurately a device follows a data
model. model.
o container: An interior node in the data tree which exist in at o container: An interior data node which exists in at most one
most one instance. A container node has no value, but rather a instance in the data tree. A container has no value, but rather a
set of child nodes. set of child nodes.
o data definition statement: A statement that defines new data o data definition statement: A statement that defines new data
nodes. One of container, leaf, leaf-list, list, choice, case, nodes. One of container, leaf, leaf-list, list, choice, case,
augment, uses, and anyxml. augment, uses, and anyxml.
o data model: A data model describes how data is represented and o data model: A data model describes how data is represented and
accessed. accessed.
o data node: A node in the schema tree that can be instantiated in a o data node: A node in the schema tree that can be instantiated in a
skipping to change at page 10, line 50 skipping to change at page 11, line 5
o data tree: The instantiated tree of configuration and state data o data tree: The instantiated tree of configuration and state data
on a device. on a device.
o derived type: A type which is derived from a built-in type (such o derived type: A type which is derived from a built-in type (such
as uint32), or another derived type. as uint32), or another derived type.
o device deviation: A failure of the device to implement the module o device deviation: A failure of the device to implement the module
faithfully. faithfully.
o extension: An extension attaches non-YANG semantics to nodes. The o extension: An extension attaches non-YANG semantics to statements.
extension statement defines new statements to express these The extension statement defines new statements to express these
semantics. semantics.
o feature: A mechanism for marking a portion of the model as o feature: A mechanism for marking a portion of the model as
optional. Definitions can be tagged with a feature name and are optional. Definitions can be tagged with a feature name and are
only valid on devices which support that feature. only valid on devices which support that feature.
o grouping: A reusable set of nodes, which may be used locally in o grouping: A reusable set of schema nodes, which may be used
the module, in modules which include it, and by other modules locally in the module, in modules which include it, and by other
which import from it. The grouping statement is not a data modules which import from it. The grouping statement is not a
definition statement and, as such, does not define any nodes in data definition statement and, as such, does not define any nodes
the schema tree. in the schema tree.
o identifier: Used to identify different kinds of YANG items by o identifier: Used to identify different kinds of YANG items by
name. name.
o instance identifier: A mechanism for identifying a particular node o instance identifier: A mechanism for identifying a particular node
in a data tree. in a data tree.
o interior node: Nodes within a hierarchy that are not leaf nodes. o interior node: Nodes within a hierarchy that are not leaf nodes.
o leaf: A node in the data tree with a value but no child nodes. o leaf: A data node which exists in at most one instance in the data
tree. A leaf has a value but no child nodes.
o leaf-list: Like the leaf node but defines a set of uniquely o leaf-list: Like the leaf node but defines a set of uniquely
identifiable nodes rather than a single node. Each node has a identifiable nodes rather than a single node. Each node has a
value but no child nodes. value but no child nodes.
o list: Interior nodes in the data tree which may exist in multiple o list: An interior data node which may exist in multiple instances
instances. A list node has no value, but rather a set of child in the data tree. A list has no value, but rather a set of child
nodes. nodes.
o module: A YANG module defines a hierarchy of nodes which can be o module: A YANG module defines a hierarchy of nodes which can be
used for NETCONF-based operations. With its definitions and the used for NETCONF-based operations. With its definitions and the
definitions it imports or includes from elsewhere, a module is definitions it imports or includes from elsewhere, a module is
self-contained and "compilable". self-contained and "compilable".
o RPC: A Remote Procedure Call, as used within the NETCONF protocol. o RPC: A Remote Procedure Call, as used within the NETCONF protocol.
o RPC method: A specific Remote Procedure Call, as used within the o RPC operation: A specific Remote Procedure Call, as used within
NETCONF protocol. Also called a protocol operation. the NETCONF protocol. Also called a protocol operation.
o schema node: A node in the schema tree. One of container, leaf, o schema node: A node in the schema tree. One of container, leaf,
leaf-list, list, choice, case, rpc, input, output, notification, leaf-list, list, choice, case, rpc, input, output, notification,
and anyxml. and anyxml.
o schema node identifier: A mechanism for identifying a particular o schema node identifier: A mechanism for identifying a particular
node in the schema tree. node in the schema tree.
o schema tree: The definition hierarchy specified within a module. o schema tree: The definition hierarchy specified within a module.
skipping to change at page 12, line 16 skipping to change at page 12, line 21
configuration data such as read-only status information and configuration data such as read-only status information and
collected statistics [RFC4741]. collected statistics [RFC4741].
o submodule: A partial module definition which contributes derived o submodule: A partial module definition which contributes derived
types, groupings, data nodes, RPCs, and notifications to a module. types, groupings, data nodes, RPCs, and notifications to a module.
A YANG module can be constructed from a number of submodules. A YANG module can be constructed from a number of submodules.
o top-level data node: A data node where there is no other data node o top-level data node: A data node where there is no other data node
between it and a module or submodule statement. between it and a module or submodule statement.
o uses: The "uses" statement is used to instantiate the set of nodes o uses: The "uses" statement is used to instantiate the set of
defined in a grouping statement. The instantiated nodes may be schema nodes defined in a grouping statement. The instantiated
refined and augmented to tailor them to any specific needs. nodes may be refined and augmented to tailor them to any specific
needs.
3.1. Mandatory nodes 3.1. Mandatory nodes
A mandatory node is one of: A mandatory node is one of:
o A leaf, choice, or anyxml node with a "mandatory" statement with o A leaf, choice, or anyxml node with a "mandatory" statement with
the value "true". the value "true".
o A list or leaf-list node with a "min-elements" statement with a o A list or leaf-list node with a "min-elements" statement with a
value greater than zero. value greater than zero.
skipping to change at page 13, line 40 skipping to change at page 13, line 40
enforceable by either the client or the server, and valid content enforceable by either the client or the server, and valid content
must abide by them. must abide by them.
YANG defines a set of built-in types, and has a type mechanism YANG defines a set of built-in types, and has a type mechanism
through which additional types may be defined. Derived types can through which additional types may be defined. Derived types can
restrict their base type's set of valid values using mechanisms like restrict their base type's set of valid values using mechanisms like
range or pattern restrictions that can be enforced by clients or range or pattern restrictions that can be enforced by clients or
servers. They can also define usage conventions for use of the servers. They can also define usage conventions for use of the
derived type, such as a string-based type that contains a host name. derived type, such as a string-based type that contains a host name.
YANG permits the definition of complex types using reusable grouping YANG permits the definition of reusable grouping of nodes. The
of nodes. The instantiation of these groupings can refine or augment instantiation of these groupings can refine or augment the nodes,
the nodes, allowing it to tailor the nodes to its particular needs. allowing it to tailor the nodes to its particular needs. Derived
Derived types and groupings can be defined in one module or submodule types and groupings can be defined in one module or submodule and
and used in either that location or in another module or submodule used in either that location or in another module or submodule that
that imports or includes it. imports or includes it.
YANG organizational constructs include defining lists where list YANG data hierarchy constructs include defining lists where list
entries are identified by keys which distinguish them from each entries are identified by keys which distinguish them from each
other. Such lists may be defined as either sorted by user or other. Such lists may be defined as either sorted by user or
automatically sorted by the system. For user-sorted lists, automatically sorted by the system. For user-sorted lists,
operations are defined for manipulating the order of the list operations are defined for manipulating the order of the list
entries. entries.
YANG modules can be translated into an XML format called YANG YANG modules can be translated into an equivalent XML syntax called
Independent Notation (YIN) (Section 11), allowing applications using YANG Independent Notation (YIN) (Section 11), allowing applications
XML parsers and XSLT scripts to operate on the models. The using XML parsers and XSLT scripts to operate on the models. The
conversion from YANG to YIN is loss-less, so content in YIN can be conversion from YANG to YIN is loss-less, so content in YIN can be
round-tripped back into YANG. round-tripped back into YANG.
YANG strikes a balance between high-level data modeling and low-level YANG strikes a balance between high-level data modeling and low-level
bits-on-the-wire encoding. The reader of a YANG module can see the bits-on-the-wire encoding. The reader of a YANG module can see the
high-level view of the data model while understanding how the data high-level view of the data model while understanding how the data
will be encoded in NETCONF operations. will be encoded in NETCONF operations.
YANG is an extensible language, allowing extension statements to be YANG is an extensible language, allowing extension statements to be
defined by standards bodies, vendors, and individuals. The statement defined by standards bodies, vendors, and individuals. The statement
syntax allows these extensions to coexist with standard YANG syntax allows these extensions to coexist with standard YANG
statements in a natural way, while making extensions stand out statements in a natural way, while extensions in a YANG module stand
sufficiently for the reader to notice them. out sufficiently for the reader to notice them.
YANG resists the tendency to solve all possible problems, limiting YANG resists the tendency to solve all possible problems, limiting
the problem space to allow expression of NETCONF data models, not the problem space to allow expression of NETCONF data models, not
arbitrary XML documents or arbitrary data models. The data models arbitrary XML documents or arbitrary data models. The data models
described by YANG are designed to be easily operated upon by NETCONF described by YANG are designed to be easily operated upon by NETCONF
operations. operations.
To the extent possible, YANG maintains compatibility with SNMP's To the extent possible, YANG maintains compatibility with SNMP's
SMIv2 (Structure of Management Information version 2 [RFC2578], SMIv2 (Structure of Management Information version 2 [RFC2578],
[RFC2579]). SMIv2-based MIB modules can be automatically translated [RFC2579]). SMIv2-based MIB modules can be automatically translated
into YANG modules for read-only access. However YANG is not into YANG modules for read-only access. However, YANG is not
concerned with reverse translation from YANG to SMIv2. concerned with reverse translation from YANG to SMIv2.
Like NETCONF, YANG targets smooth integration with device's native Like NETCONF, YANG targets smooth integration with device's native
management infrastructure. This allows implementations to leverage management infrastructure. This allows implementations to leverage
their existing access control mechanisms to protect or expose their existing access control mechanisms to protect or expose
elements of the data model. elements of the data model.
4.2. Language Overview 4.2. Language Overview
This section introduces some important constructs used in YANG that This section introduces some important constructs used in YANG that
skipping to change at page 16, line 51 skipping to change at page 16, line 51
<message>Good morning, Dave</message> <message>Good morning, Dave</message>
</login> </login>
</system> </system>
The "container" statement is covered in Section 7.5. The "container" statement is covered in Section 7.5.
4.2.2.4. List Nodes 4.2.2.4. List Nodes
A list defines a sequence of list entries. Each entry is like a A list defines a sequence of list entries. Each entry is like a
structure or a record instance, and is uniquely identified by the structure or a record instance, and is uniquely identified by the
values of its key leafs. A list can define multiple keys and may values of its key leafs. A list can define multiple key leafs and
contain any number of child nodes of any type (including leafs, may contain any number of child nodes of any type (including leafs,
lists, containers etc.). lists, containers etc.).
YANG Example: YANG Example:
list user { list user {
key "name"; key "name";
leaf name { leaf name {
type string; type string;
} }
leaf full-name { leaf full-name {
skipping to change at page 20, line 5 skipping to change at page 20, line 5
} }
} }
4.2.4. Built-in Types 4.2.4. Built-in Types
YANG has a set of built-in types, similar to those of many YANG has a set of built-in types, similar to those of many
programming languages, but with some differences due to special programming languages, but with some differences due to special
requirements from the management domain. The following table requirements from the management domain. The following table
summarizes the built-in types discussed in Section 9: summarizes the built-in types discussed in Section 9:
+---------------------+-------------+-------------------------------+ +---------------------+---------------------------------------------+
| Name | Type | Description | | Name | Description |
+---------------------+-------------+-------------------------------+ +---------------------+---------------------------------------------+
| binary | Text | Any binary data | | binary | Any binary data |
| bits | Text/Number | A set of bits or flags | | bits | A set of bits or flags |
| boolean | Text | "true" or "false" | | boolean | "true" or "false" |
| decimal64 | Number | 64-bit signed decimal number | | decimal64 | 64-bit signed decimal number |
| empty | Empty | A leaf that does not have any | | empty | A leaf that does not have any value |
| | | value | | enumeration | Enumerated strings with associated numeric |
| enumeration | Text/Number | Enumerated strings with | | | values |
| | | associated numeric values | | identityref | A reference to an abstract identity |
| identityref | Text | A reference to an abstract | | instance-identifier | References a data tree node |
| | | identity | | int8 | 8-bit signed integer |
| instance-identifier | Text | References a data tree node | | int16 | 16-bit signed integer |
| int8 | Number | 8-bit signed integer | | int32 | 32-bit signed integer |
| int16 | Number | 16-bit signed integer | | int64 | 64-bit signed integer |
| int32 | Number | 32-bit signed integer | | leafref | A reference to a leaf instance |
| int64 | Number | 64-bit signed integer | | string | Human readable string |
| leafref | Text/Number | A reference to a leaf | | uint8 | 8-bit unsigned integer |
| | | instance | | uint16 | 16-bit unsigned integer |
| string | Text | Human readable string | | uint32 | 32-bit unsigned integer |
| uint8 | Number | 8-bit unsigned integer | | uint64 | 64-bit unsigned integer |
| uint16 | Number | 16-bit unsigned integer | | union | Choice of member types |
| uint32 | Number | 32-bit unsigned integer | +---------------------+---------------------------------------------+
| uint64 | Number | 64-bit unsigned integer |
| union | Text/Number | Choice of member types |
+---------------------+-------------+-------------------------------+
The "type" statement is covered in Section 7.4. The "type" statement is covered in Section 7.4.
4.2.5. Derived Types (typedef) 4.2.5. Derived Types (typedef)
YANG can define derived types from base types using the "typedef" YANG can define derived types from base types using the "typedef"
statement. A base type can be either a built-in type or a derived statement. A base type can be either a built-in type or a derived
type, allowing a hierarchy of derived types. type, allowing a hierarchy of derived types.
A derived type can be used as the argument for the "type" statement. A derived type can be used as the argument for the "type" statement.
skipping to change at page 21, line 24 skipping to change at page 21, line 13
} }
NETCONF XML Example: NETCONF XML Example:
<completed>20</completed> <completed>20</completed>
The "typedef" statement is covered in Section 7.3. The "typedef" statement is covered in Section 7.3.
4.2.6. Reusable Node Groups (grouping) 4.2.6. Reusable Node Groups (grouping)
Groups of nodes can be assembled into the equivalent of complex types Groups of nodes can be assembled into reusable collections using the
using the "grouping" statement. "grouping" defines a set of nodes "grouping" statement. A grouping defines a set of nodes that are
that are instantiated with the "uses" statement: instantiated with the "uses" statement:
grouping target { grouping target {
leaf address { leaf address {
type inet:ip-address; type inet:ip-address;
description "Target IP address"; description "Target IP address";
} }
leaf port { leaf port {
type inet:port-number; type inet:port-number;
description "Target port number"; description "Target port number";
} }
skipping to change at page 24, line 35 skipping to change at page 24, line 35
<name>alicew</name> <name>alicew</name>
<full-name>Alice N. Wonderland</full-name> <full-name>Alice N. Wonderland</full-name>
<class>drop-out</class> <class>drop-out</class>
<other:uid>1024</other:uid> <other:uid>1024</other:uid>
</user> </user>
The "augment" statement is covered in Section 7.15. The "augment" statement is covered in Section 7.15.
4.2.9. RPC Definitions 4.2.9. RPC Definitions
YANG allows the definition of NETCONF RPCs. The method names, input YANG allows the definition of NETCONF RPCs. The operation names,
parameters and output parameters are modeled using YANG data input parameters and output parameters are modeled using YANG data
definition statements. definition statements.
YANG Example: YANG Example:
rpc activate-software-image { rpc activate-software-image {
input { input {
leaf image-name { leaf image-name {
type string; type string;
} }
} }
skipping to change at page 29, line 8 skipping to change at page 29, line 8
in the import statement. in the import statement.
5.1.2. Module Hierarchies 5.1.2. Module Hierarchies
YANG allows modeling of data in multiple hierarchies, where data may YANG allows modeling of data in multiple hierarchies, where data may
have more than one top-level node. Models that have multiple top- have more than one top-level node. Models that have multiple top-
level nodes are sometimes convenient, and are supported by YANG. level nodes are sometimes convenient, and are supported by YANG.
NETCONF is capable of carrying any XML content as the payload in the NETCONF is capable of carrying any XML content as the payload in the
<config> and <data> elements. The top-level nodes of YANG modules <config> and <data> elements. The top-level nodes of YANG modules
are encoded as child elements within these elements. This are encoded as child elements, in any order, within these elements.
encapsulation guarantees that the corresponding NETCONF PDUs are This encapsulation guarantees that the corresponding NETCONF PDUs are
always well-formed XML documents. always well-formed XML documents.
For example: For example:
module my-config { module my-config {
namespace "http://example.com/schema/config"; namespace "http://example.com/schema/config";
prefix "co"; prefix "co";
container system { ... } container system { ... }
container routing { ... } container routing { ... }
skipping to change at page 29, line 47 skipping to change at page 29, line 47
</routing> </routing>
</config> </config>
</edit-config> </edit-config>
</rpc> </rpc>
5.2. File Layout 5.2. File Layout
YANG modules and submodules are typically stored in files, one module YANG modules and submodules are typically stored in files, one module
or submodule per file. The name of the file SHOULD be of the form: or submodule per file. The name of the file SHOULD be of the form:
module-or-submodule-name ['.' revision-date] ( '.yang' / '.yin' ) module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' )
YANG compilers can find imported modules and included submodules via YANG compilers can find imported modules and included submodules via
this convention. While the YANG language defines modules, tools may this convention. While the YANG language defines modules, tools may
compile submodules independently for performance and manageability compile submodules independently for performance and manageability
reasons. Many errors and warnings that cannot be detected during reasons. Errors and warnings that cannot be detected during
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 modules published in RFC streams MUST be assigned by Namespaces for modules published in RFC streams [RFC4844] MUST be
IANA, see Section 14. 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. Namespace URIs MUST be owning the module without a central registry. Namespace URIs MUST be
choosen so they cannot collide with standard or other enterprise chosen so they cannot collide with standard or other enterprise
namespaces, for example by using the enterprise or organization name namespaces, for example by using the enterprise or organization name
in the namespace. in the namespace.
The "namespace" statement is covered in Section 7.1.3. The "namespace" statement is covered in Section 7.1.3.
5.3.1. YANG XML Namespace 5.3.1. YANG XML Namespace
YANG defines an XML namespace for NETCONF <edit-config> operations YANG defines an XML namespace for NETCONF <edit-config> operations
and <error-info> content. This namespace is and <error-info> content. The name of this namespace is
"urn:ietf:params:xml:ns:yang:1". "urn:ietf:params:xml:ns:yang:1".
5.4. Resolving Grouping, Type, and Identity Names 5.4. Resolving Grouping, Type, and Identity Names
Grouping, type, and identity names are resolved in the context in Grouping, type, and identity names are resolved in the context in
which they are defined, rather than the context in which they are which they are defined, rather than the context in which they are
used. Users of groupings, typedefs, and identities are not required used. Users of groupings, typedefs, and identities are not required
to import modules or include submodules to satisfy all references to import modules or include submodules to satisfy all references
made by the original definition. This behaves like static scoping in made by the original definition. This behaves like static scoping in
a conventional programming language. a conventional programming language.
skipping to change at page 32, line 10 skipping to change at page 32, line 10
o deviations from the model o deviations from the model
We will consider each of these in sequence. We will consider each of these in sequence.
5.6.1. Basic Behavior 5.6.1. Basic Behavior
The model defines a contract between the NETCONF client and server, The model defines a contract between the NETCONF client and server,
which allows both parties to have faith the other knows the syntax which allows both parties to have faith the other knows the syntax
and semantics behind the modeled data. The strength of YANG lies in and semantics behind the modeled data. The strength of YANG lies in
the strength of this contract and the mindless devotion with which the strength of this contract.
implementers follow it.
5.6.2. Optional Features 5.6.2. Optional Features
In many models, the modeler will allow sections of the model to be In many models, the modeler will allow sections of the model to be
conditional, based on the device. The device controls whether these conditional. The device controls whether these conditional portions
conditional portions of the model are supported or valid for that of the model are supported or valid for that particular device.
particular device.
For example, a syslog data model may choose to include the ability to For example, a syslog data model may choose to include the ability to
save logs locally, but the modeler will realize that this is only save logs locally, but the modeler will realize that this is only
possible if the device has local storage. If there is no local possible if the device has local storage. If there is no local
storage, an application should not tell the device to save logs. storage, an application should not tell the device to save logs.
YANG supports this conditional mechanism using a construct called YANG supports this conditional mechanism using a construct called
"feature". Features give the modeler a mechanism for making portions "feature". Features give the modeler a mechanism for making portions
of the module conditional in a manner that is controlled by the of the module conditional in a manner that is controlled by the
device. The model can express constructs which are not universally device. The model can express constructs which are not universally
skipping to change at page 32, line 52 skipping to change at page 32, line 50
the module that are conditional to the feature are noted by the the module that are conditional to the feature are noted by the
"if-feature" statement with the name of the feature as its argument. "if-feature" statement 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 designed to implement the model as written. For YANG-based
to deal with these device deviations, a mechanism must exist for automation to deal with these device deviations, a mechanism must
devices to inform applications of the specifics of such deviations. exist for devices to inform applications of the specifics of such
deviations.
For example, a BGP module may allow any number of BGP peers, but a For example, a BGP module may allow any number of BGP peers, but a
particular device may only support 16 BGP peers. Any application particular device may only support 16 BGP peers. Any application
configuring the 17th peer will receive an error. While an error may configuring the 17th peer will receive an error. While an error may
suffice to let the application know it cannot add another peer, it suffice to let the application know it cannot add another peer, it
would be far better if the application had prior knowledge of this would be far better if the application had prior knowledge of this
limitation and could prevent the user from starting down the path limitation and could prevent the user from starting down the path
that could not succeed. that could not succeed.
Device deviations are declared using the "deviation" statement, which Device deviations are declared using the "deviation" statement, which
skipping to change at page 33, line 41 skipping to change at page 33, line 40
feature-parameter / feature-parameter /
deviation-parameter deviation-parameter
revision-parameter = "revision=" revision-date revision-parameter = "revision=" revision-date
module-parameter = "module=" module-name module-parameter = "module=" module-name
feature-parameter = "features=" feature *( "," feature ) feature-parameter = "features=" feature *( "," feature )
deviation-parameter = "deviations=" deviation *( "," deviation ) deviation-parameter = "deviations=" deviation *( "," deviation )
Where "revision-date" is the revision of the module (see Where "revision-date" is the revision of the module (see
Section 7.1.9) that the NETCONF server implements, "module-name" is Section 7.1.9) that the NETCONF server implements, "module-name" is
the name of module as it appears in the "module" statement (see the name of module as it appears in the "module" statement (see
Section 7.1), "namespace-uri" is the namespace for the module as it Section 7.1), "namespace-uri" is the namespace URI for the module as
appears in the "namespace" statement, "feature" is the name of an it appears in the "namespace" statement, "feature" is the name of an
optional feature implemented by the device (see Section 7.18.1), and optional feature implemented by the device (see Section 7.18.1), and
"deviation" is the name of a module defining device deviations (see "deviation" is the name of a module defining device deviations (see
Section 7.18.3). Section 7.18.3).
In the parameter list, each named parameter MUST occur at most once. In the parameter list, each named parameter MUST occur at most once.
5.6.4.1. Modules 5.6.4.1. Modules
Servers indicate the names of supported modules via the <hello> Servers indicate the names of supported modules via the <hello>
message. Module namespaces are encoded as the base URI in the message. Module namespaces are encoded as the base URI in the
skipping to change at page 35, line 12 skipping to change at page 35, line 4
the client that it deviates from module "syslog" according to the the client that it deviates from module "syslog" according to the
deviations listed in the module "my-devs". deviations listed in the module "my-devs".
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capability> <capability>
http://example.com/syslog?module=syslog&deviations=my-devs http://example.com/syslog?module=syslog&deviations=my-devs
</capability> </capability>
<capability> <capability>
http://example.com/my-deviations?module=my-devs http://example.com/my-deviations?module=my-devs
</capability> </capability>
</hello> </hello>
5.7. Data Store Modification 5.7. Data Store Modification
Data models may allow the server to alter the configuration data Data models may allow the server to alter the configuration data
store. A formal mechanism for specifying the circumstances where store in ways not explicitly directed via NETCONF protocol messages.
these changes are allowed is out of scope for this specification. For example, a data model may define leafs that are assigned system-
generated values when the client does not provide one. A formal
mechanism for specifying the circumstances where these changes are
allowed is out of scope for this specification.
6. YANG syntax 6. YANG syntax
The YANG syntax is similar to that of SMIng [RFC3780] and programming The YANG syntax is similar to that of SMIng [RFC3780] and programming
languages like C and C++. This C-like syntax was chosen specifically languages like C and C++. This C-like syntax was chosen specifically
for its readability, since YANG values the time and effort of the for its readability, since YANG values the time and effort of the
readers of models above those of modules writers and YANG tool-chain readers of models above those of modules writers and YANG tool-chain
developers. This section introduces the YANG syntax. developers. This section introduces the YANG syntax.
YANG modules use the UTF-8 [RFC3629] character encoding. YANG modules use the UTF-8 [RFC3629] character encoding.
skipping to change at page 36, line 34 skipping to change at page 36, line 34
6.1.1. Comments 6.1.1. Comments
Comments are C++ style. A single line comment starts with "//" and Comments are C++ style. A single line comment starts with "//" and
ends at the end of the line. A block comment is enclosed within "/*" ends at the end of the line. A block comment is enclosed within "/*"
and "*/". and "*/".
6.1.2. Tokens 6.1.2. Tokens
A token in YANG is either a keyword, a string, ";", "{", or "}". A A token in YANG is either a keyword, a string, ";", "{", or "}". A
string can be quoted or unquoted. A keyword is either one of the string can be quoted or unquoted. A keyword is either one of the
core YANG keywords defined in this document, or a prefix identifier, YANG keywords defined in this document, or a prefix identifier,
followed by ":", followed by a language extension keyword. Keywords followed by ":", followed by a language extension keyword. Keywords
are case sensitive. See Section 6.2 for a formal definition of are case sensitive. See Section 6.2 for a formal definition of
identifiers. identifiers.
6.1.3. Quoting 6.1.3. Quoting
If a string contains any space or tab characters, a semicolon (";"), If a string contains any space or tab characters, a semicolon (";"),
braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then
it MUST be enclosed within double or single quotes. it MUST be enclosed within double or single quotes.
skipping to change at page 42, line 7 skipping to change at page 42, line 7
References to identifiers defined in external modules MUST be References to identifiers defined in external modules MUST be
qualified with appropriate prefixes, and references to identifiers qualified with appropriate prefixes, and references to identifiers
defined in the current module and its submodules MAY use a prefix. defined in the current module and its submodules MAY use a prefix.
For example, to identify the child node "b" of top-level node "a", For example, to identify the child node "b" of top-level node "a",
the string "/a/b" can be used. the string "/a/b" can be used.
7. YANG Statements 7. YANG Statements
The following sections describe all of the YANG core statements. The following sections describe all of the YANG statements.
Note that even a statement which does not have any substatements Note that even a statement which does not have any substatements
defined in core YANG can have vendor-specific extensions as defined in YANG can have vendor-specific extensions as substatements.
substatements. For example, the "description" statement does not For example, the "description" statement does not have any
have any substatements defined in core YANG, but the following is substatements defined in YANG, but the following is legal:
legal:
description "some text" { description "some text" {
acme:documentation-flag 5; acme:documentation-flag 5;
} }
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.
Names of modules published in RFC streams MUST be assigned by IANA, Names of modules published in RFC streams [RFC4844] MUST be assigned
see Section 14. 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
module names that will have a low probability of colliding with module names that will have a low probability of colliding with
standard or other enterprise modules and submodules, e.g., by using standard or other enterprise modules and submodules, e.g., by using
the enterprise or organization name as a prefix. the enterprise or organization name as a prefix for the module name.
A module SHOULD have the following layout: A module SHOULD have the following layout:
module <module-name> { module <module-name> {
// header information // header information
<yang-version statement> <yang-version statement>
<namespace statement> <namespace statement>
<prefix statement> <prefix statement>
skipping to change at page 44, line 40 skipping to change at page 44, line 40
| typedef | 7.3 | 0..n | | typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n | | uses | 7.12 | 0..n |
| yang-version | 7.1.2 | 0..1 | | yang-version | 7.1.2 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.1.2. The yang-version Statement 7.1.2. The yang-version Statement
The optional "yang-version" statement specifies which version of the The optional "yang-version" statement specifies which version of the
YANG language was used in developing the module. The statement's YANG language was used in developing the module. The statement's
argument is a string. If present, it MUST contain the value "1", argument is a string. If present, it MUST contain the value "1",
which is the current yang version and the default value. which is the current YANG version and the default value.
7.1.3. The namespace Statement 7.1.3. The namespace Statement
The "namespace" statement defines the XML namespace to which all The "namespace" statement defines the XML namespace to which all
identifiers defined by the module belong, with the exception of data identifiers defined by the module belong, with the exception of data
node identifiers defined inside a grouping (see Section 7.12 for node identifiers defined inside a grouping (see Section 7.12 for
details). The argument to the "namespace" statement is the URI of details). The argument to the "namespace" statement is the URI of
the namespace. the namespace.
See also Section 5.3. See also Section 5.3.
skipping to change at page 45, line 17 skipping to change at page 45, line 17
The "prefix" statement is used to define the prefix associated with The "prefix" statement is used to define the prefix associated with
the module and its namespace. The "prefix" statement's argument is the module and its namespace. The "prefix" statement's argument is
the prefix string which is used as a prefix to access a module. The the prefix string which is used as a prefix to access a module. The
prefix string MAY be used to refer to definitions contained in the prefix string MAY be used to refer to definitions contained in the
module, e.g., "if:ifName". A prefix follows the same rules as an module, e.g., "if:ifName". A prefix follows the same rules as an
identifier (see Section 6.2). identifier (see Section 6.2).
When used inside the "module" statement, the "prefix" statement When used inside the "module" statement, the "prefix" statement
defines the prefix to be used when this module is imported. To defines the prefix to be used when this module is imported. To
improve readability of the NETCONF XML, a NETCONF client or server improve readability of the NETCONF XML, a NETCONF client or server
which generates XML or XPath that use prefixes, the prefix defined by which generates XML or XPath that use prefixes SHOULD use the prefix
a module SHOULD be used, unless there is a conflict. defined by the module, unless there is a conflict.
When used inside the "import" statement, the "prefix" statement When used inside the "import" statement, the "prefix" statement
defines the prefix to be used when accessing definitions inside the defines the prefix to be used when accessing definitions inside the
imported module. When a reference to an identifier from the imported imported module. When a reference to an identifier from the imported
module is used, the prefix string for the imported module is used in module is used, the prefix string for the imported module is used in
combination with a colon (":") and the identifier, e.g., "if: combination with a colon (":") and the identifier, e.g., "if:
ifIndex". To improve readability of YANG modules, the prefix defined ifIndex". To improve readability of YANG modules, the prefix defined
by a module SHOULD be used when the module is imported, unless there by a module SHOULD be used when the module is imported, unless there
is a conflict. is a conflict.
skipping to change at page 45, line 46 skipping to change at page 45, line 46
module to import, and the statement is followed by a block of module to import, and the statement is followed by a block of
substatements that holds detailed import information. When a module substatements that holds detailed import information. When a module
is imported, the importing module may: is imported, the importing module may:
o use any grouping and typedef defined at the top-level in the o use any grouping and typedef defined at the top-level in the
imported module or its submodules imported module or its submodules
o use any extension, feature, and identity defined in the imported o use any extension, feature, and identity defined in the imported
module or its submodules module or its submodules
o use any node in the imported module's schema tree in augment, o use any node in the imported module's schema tree in "must",
must, path, and when statements "path", and "when" statements, or as the target node in an
"augment" statement
The mandatory "prefix" substatement assigns a prefix for the imported The mandatory "prefix" substatement assigns a prefix for the imported
module which is scoped to the importing module or submodule. module which is scoped to the importing module or submodule.
Multiple "import" statements may be specified to import from Multiple "import" statements may be specified to import from
different modules. different modules.
When the optional "revision-date" substatement is present, any When the optional "revision-date" substatement is present, any
typedef, grouping, extension, feature, and identity referenced by typedef, grouping, extension, feature, and identity referenced by
definitions in the local module are taken from the specified revision definitions in the local module are taken from the specified revision
of the imported module. Otherwise, it is undefined from which of the imported module. Otherwise, it is undefined from which
skipping to change at page 47, line 30 skipping to change at page 47, line 30
7.1.8. The contact Statement 7.1.8. The contact Statement
The "contact" statement provides contact information for the module. The "contact" statement provides contact information for the module.
The argument is a string which is used to specify the name, postal The argument is a string which is used to specify the name, postal
address, telephone number, and electronic mail address of the person address, telephone number, and electronic mail address of the person
to whom technical queries concerning this module should be sent. to whom technical queries concerning this module should be sent.
7.1.9. The revision Statement 7.1.9. The revision Statement
The "revision" statement specifies the editorial revision history of The "revision" statement specifies the editorial revision history of
the module, including the initial revision. A series of revisions the module, including the initial revision. A series of revision
statements detail the changes in the module's definition. The statements detail the changes in the module's definition. The
argument is a date string in the format "YYYY-MM-DD", followed by a argument is a date string in the format "YYYY-MM-DD", followed by a
block of substatements that holds detailed revision information. A block of substatements that holds detailed revision information. A
module SHOULD have at least one initial "revision" statement. For module SHOULD have at least one initial "revision" statement. For
every published editorial change, a new one SHOULD be added in front every published editorial change, a new one SHOULD be added in front
of the revisions sequence, so that all revisions are in reverse of the revisions sequence, so that all revisions are in reverse
chronological order. chronological order.
7.1.9.1. The revision's Substatement 7.1.9.1. The revision's Substatement
skipping to change at page 48, line 36 skipping to change at page 48, line 36
Phone: +1 800 555 0100 Phone: +1 800 555 0100
EMail: joe@acme.example.com"; EMail: joe@acme.example.com";
description description
"The module for entities implementing the ACME protocol."; "The module for entities implementing the ACME protocol.";
revision "2007-06-09" { revision "2007-06-09" {
description "Initial revision."; description "Initial revision.";
} }
// definitions follows... // definitions follow...
} }
7.2. The submodule Statement 7.2. The submodule Statement
While the primary unit in YANG is a module, a YANG module can itself While the primary unit in YANG is a module, a YANG module can itself
be constructed out of several submodules. Submodules allow a module be constructed out of several submodules. Submodules allow a module
designer to split a complex model into several pieces where all the designer to split a complex model into several pieces where all the
submodules contribute to a single namespace, which is defined by the submodules contribute to a single namespace, which is defined by the
module that includes the submodules. module that includes the submodules.
The "submodule" statement defines the submodule's name, and groups The "submodule" statement defines the submodule's name, and groups
all statements which belong to the submodule together. The all statements which belong to the submodule together. The
"submodule" statement's argument is the name of the submodule, "submodule" statement's argument is the name of the submodule,
followed by a block of substatements that hold detailed submodule followed by a block of substatements that hold detailed submodule
information. The submodule name follows the rules for identifiers in information. The submodule name follows the rules for identifiers in
Section 6.2. Section 6.2.
Names of submodules published in RFC streams MUST be assigned by Names of submodules published in RFC streams [RFC4844] MUST be
IANA, see Section 14. 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 for the submodule
name.
A submodule SHOULD have the following layout: A submodule SHOULD have the following layout:
submodule <module-name> { submodule <module-name> {
<yang-version statement> <yang-version statement>
// module identification // module identification
<belongs-to statement> <belongs-to statement>
skipping to change at page 53, line 45 skipping to change at page 53, line 45
| length | 9.4.4 | 0..1 | | length | 9.4.4 | 0..1 |
| path | 9.9.2 | 0..1 | | path | 9.9.2 | 0..1 |
| pattern | 9.4.6 | 0..n | | pattern | 9.4.6 | 0..n |
| range | 9.2.4 | 0..1 | | range | 9.2.4 | 0..1 |
| require-instance | 9.13.2 | 0..1 | | require-instance | 9.13.2 | 0..1 |
| type | 7.4 | 0..n | | type | 7.4 | 0..n |
+------------------+---------+-------------+ +------------------+---------+-------------+
7.5. The container Statement 7.5. The container Statement
The "container" statement is used to define an interior node in the The "container" statement is used to define an interior data node in
schema tree. It takes one argument, which is an identifier, followed the schema tree. It takes one argument, which is an identifier,
by a block of substatements that holds detailed container followed by a block of substatements that holds detailed container
information. information.
A container node does not have a value, but it has a list of child A container node does not have a value, but it has a list of child
nodes in the data tree. The child nodes are defined in the nodes in the data tree. The child nodes are defined in the
container's substatements. container's substatements.
7.5.1. Containers with Presence 7.5.1. Containers with Presence
YANG supports two styles of containers, those which exist only for YANG supports two styles of containers, those which exist only for
organizing the hierarchy of data nodes, and those whose presence in organizing the hierarchy of data nodes, and those whose presence in
the configuration has an explicit meaning. the configuration has an explicit meaning.
In the first style, the container has no meaning of its own, existing In the first style, the container has no meaning of its own, existing
only to contain child nodes. This is the default style. only to contain child nodes. This is the default style.
For example, the set of scrambling options for SONET interfaces may For example, the set of scrambling options for SONET interfaces may
be placed inside a "scrambling" container to enhance the organization be placed inside a "scrambling" container to enhance the organization
of the configuration hierarchy, and to keep these nodes together. of the configuration hierarchy, and to keep these nodes together.
The "scrambling" node itself has no meaning, so removing the node The "scrambling" node itself has no meaning, so removing the node
when it becomes empty relieves the user from the task of performing when it becomes empty relieves the user from performing this task.
this task.
In the second style, the presence of the container itself is In the second style, the presence of the container itself is
configuration data, representing a single bit of configuration data. configuration data, representing a single bit of configuration data.
The container acts as both a configuration knob and a means of The container acts as both a configuration knob and a means of
organizing related configuration. These containers are explicitly organizing related configuration. These containers are explicitly
created and deleted. created and deleted.
YANG calls this style a "presence container" and they are indicated YANG calls this style a "presence container" and it is indicated
using the "presence" statement, which takes as its argument a text using the "presence" statement, which takes as its argument a text
string indicating what the presence of the node means. string indicating what the presence of the node means.
For example, an "ssh" container may turn on the ability to log into For example, an "ssh" container may turn on the ability to log into
the device using ssh, but can also contain any ssh-related the device using ssh, but can also contain any ssh-related
configuration knobs, such as connection rates or retry limits. configuration knobs, such as connection rates or retry limits.
The "presence" statement (see Section 7.5.5) is used to give The "presence" statement (see Section 7.5.5) is used to give
semantics to the existence of the container in the data tree. semantics to the existence of the container in the data tree.
skipping to change at page 55, line 37 skipping to change at page 55, line 37
+--------------+---------+-------------+ +--------------+---------+-------------+
7.5.3. The must Statement 7.5.3. The must Statement
The "must" statement, which is optional, takes as an argument a The "must" statement, which is optional, takes as an argument a
string which contains an XPath expression. It is used to formally string which contains an XPath expression. It is used to formally
declare a constraint on valid data. The constraint is enforced declare a constraint on valid data. The constraint is enforced
according to the rules in Section 8. according to the rules in Section 8.
When a datastore is validated, all "must" constraints are When a datastore is validated, all "must" constraints are
conceptually evaluated once for each corresponding instance in the conceptually evaluated once for each data node in the data tree, and
data tree, and for all leafs with default values in use (see for all leafs with default values in use (see Section 7.6.1). If a
Section 7.6.1). If an instance does not exist in the data tree, and data node does not exist in the data tree, and it does not have a
it does not have a default value, its "must" statements are not default value, its "must" statements are not evaluated.
evaluated.
All such constraints MUST evaluate to true for the data to be valid. All such constraints MUST evaluate to true for the data to be valid.
The XPath expression is conceptually evaluated in the following The XPath expression is conceptually evaluated in the following
context, in addition to the definition in Section 6.4.1: context, in addition to the definition in Section 6.4.1:
o The context node is the node in the data tree for which the "must" o The context node is the node in the data tree for which the "must"
statement is defined. statement is defined.
o The accessible tree is made up of all nodes in the data tree, and o The accessible tree is made up of all nodes in the data tree, and
skipping to change at page 56, line 23 skipping to change at page 56, line 23
data on the device, and the <running/> datastore. The XPath root data on the device, and the <running/> datastore. The XPath root
node has all top-level data nodes in all modules as children. node has all top-level data nodes in all modules as children.
o If the context node represents notification content, the tree is o If the context node represents notification content, the tree is
the notification XML instance document. The XPath root node has the notification XML instance document. The XPath root node has
the element representing the notification being defined as the the element representing the notification being defined as the
only child. only child.
o If the context node represents RPC input parameters, the tree is o If the context node represents RPC input parameters, the tree is
the RPC XML instance document. The XPath root node has the the RPC XML instance document. The XPath root node has the
element representing the RPC method being defined as the only element representing the RPC operation 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.
Note that since all leaf values in the data tree are conceptually Note that since all leaf values in the data tree are conceptually
skipping to change at page 58, line 26 skipping to change at page 58, line 26
See Section 7.5.1 for additional information. See Section 7.5.1 for additional information.
7.5.6. The container's Child Node Statements 7.5.6. The container's Child Node Statements
Within a container, the "container", "leaf", "list", "leaf-list", Within a container, the "container", "leaf", "list", "leaf-list",
"uses", "choice", and "anyxml" statements can be used to define child "uses", "choice", and "anyxml" statements can be used to define child
nodes to the container. nodes to the container.
7.5.7. XML Mapping Rules 7.5.7. XML Mapping 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 local
the container's identifier, and its XML namespace is the module's XML name is the container's identifier, and its namespace is the module's
namespace. XML namespace (see Section 7.1.3).
The container's child nodes are encoded as subelements to the The container's child nodes are encoded as subelements to the
container element. If the container defines RPC input or output container element. If the container defines RPC input or output
parameters, the subelements are encoded in the same order as they are parameters, these subelements are encoded in the same order as they
defined within the container statement. Otherwise, the subelements are defined within the container statement. Otherwise, the
are encoded in any order. 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
Containers can be created, deleted, replaced and modified through Containers can be created, deleted, replaced and modified through
<edit-config>, by using the "operation" attribute (See [RFC4741], <edit-config>, by using the "operation" attribute (See [RFC4741],
section 7.2) in the container's XML element. section 7.2) in the container's XML element.
If a container does not have a "presence" statement and the last If a container does not have a "presence" statement and the last
child node is deleted, the NETCONF server MAY delete the container. child node is deleted, the NETCONF server MAY delete the container.
When a NETCONF server processes an <edit-config> request, the
elements of procedure for the container node are:
If the operation is "merge" or "replace", the node is created if
it does not exist.
If the operation is "create" the node is created if it does not
exist. If the node already exists, a "data-exists" error is
returned.
If the operation is "delete" the node is deleted if it exists. If
the node does not exist, a "data-missing" error is returned.
7.5.9. Usage Example 7.5.9. Usage Example
Given the following container definition: Given the following container definition:
container system { container system {
description "Contains various system parameters"; description "Contains various system parameters";
container services { container services {
description "Configure externally available services"; description "Configure externally available services";
container "ssh" { container "ssh" {
presence "Enables SSH"; presence "Enables SSH";
skipping to change at page 62, line 18 skipping to change at page 62, line 31
o Otherwise, if this ancestor is a case node, the leaf MUST exist if o Otherwise, if this ancestor is a case node, the leaf MUST exist if
any node from the case exists in the data tree. any node from the case exists in the data tree.
o Otherwise, the leaf MUST exist if the ancestor node exists in the o Otherwise, the leaf MUST exist if the ancestor node exists in the
data tree. data tree.
This constraint is enforced according to the rules in Section 8. This constraint is enforced according to the rules in Section 8.
7.6.6. XML Mapping Rules 7.6.6. XML Mapping Rules
A leaf node is encoded as an XML element. The element's name is the A leaf node is encoded as an XML element. The element's local name
leaf's identifier, and its XML namespace is the module's XML is the leaf's identifier, and its namespace is the module's XML
namespace. namespace (see Section 7.1.3).
The value of the leaf node is encoded to XML according to the type, The value of the leaf node is encoded to XML according to the type,
and sent as character data in the element. and sent as character data in the element.
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 the leaf element if its value is the default choose not to send the leaf element if its value is the default
value. Thus, a client that receives an <rpc-reply> for a <get> or value. Thus, a client that receives an <rpc-reply> for a <get> or
<get-config> request, MUST be prepared to handle the case that a leaf <get-config> request, MUST be prepared to handle the case that a leaf
node with a default value is not present in the XML. In this case, node with a default value is not present in the XML. In this case,
the value used by the server is known to be the default value. the value used by the server is known to be the default value.
See Section 7.6.8 for an example. See Section 7.6.8 for an example.
7.6.7. NETCONF <edit-config> Operations 7.6.7. NETCONF <edit-config> Operations
When a NETCONF server processes an <edit-config> request, the When a NETCONF server processes an <edit-config> request, the
elements of procedure for the leaf node are: elements of procedure for the leaf node are:
If the operation is "merge", the node is created if it does not If the operation is "merge" or "replace", the node is created if
exist, and its value is set to the value found in the XML RPC it does not exist, and its value is set to the value found in the
data. XML RPC data.
If the operation is "replace", the node is created if it does not
exist, and its value is set to the value found in the XML RPC
data.
If the operation is "create" the node is created if it does not If the operation is "create" the node is created if it does not
exist. exist. If the node already exists, a "data-exists" error is
returned.
If the operation is "delete" the node is deleted if it exists. If the operation is "delete" the node is deleted if it exists. If
the node does not exist, a "data-missing" error is returned.
7.6.8. Usage Example 7.6.8. Usage Example
Given the following leaf statement, placed in the previously defined Given the following leaf statement, placed in the previously defined
"ssh" container (See Section 7.5.9): "ssh" container (See Section 7.5.9):
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 instance example: A corresponding XML instance example:
<port>2022</port> <port>2022</port>
To create a leaf with an <edit-config>: To set the value of 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 66, line 40 skipping to change at page 66, line 43
7.7.5.2. ordered-by user 7.7.5.2. ordered-by user
The entries in the list are sorted according to an order defined by The entries in the list are sorted according to an order defined by
the user. This order is controlled by using special XML attributes the user. This order is controlled by using special XML attributes
in the <edit-config> request. See Section 7.7.7 for details. in the <edit-config> request. See Section 7.7.7 for details.
7.7.6. XML Mapping Rules 7.7.6. XML Mapping Rules
A leaf-list node is encoded as a series of XML elements. Each A leaf-list node is encoded as a series of XML elements. Each
element's name is the leaf-list's identifier, and its XML namespace element's local name is the leaf-list's identifier, and its namespace
is the module's XML namespace. is the module's XML namespace (see Section 7.1.3).
The value of the leaf-list node is encoded to XML according to the The value of each leaf-list entry is encoded to XML according to the
type, and sent as character data in the element. type, and sent as character data in the element.
The XML elements representing leaf-list entries MUST appear in the The XML elements representing leaf-list entries MUST appear in the
order specified by the user if the leaf-list is "ordered-by user", order specified by the user if the leaf-list is "ordered-by user",
otherwise the order is implementation-dependent. The XML elements otherwise the order is implementation-dependent. The XML elements
representing leaf-list entries MAY be interleaved with other sibling representing leaf-list entries MAY be interleaved with other sibling
elements, unless the leaf-list defines RPC input or output elements, unless the leaf-list defines RPC input or output
parameters. parameters.
See Section 7.7.8 for an example. See Section 7.7.8 for an example.
7.7.7. NETCONF <edit-config> operations 7.7.7. NETCONF <edit-config> Operations
Leaf-list entries can be created and deleted, but not modified, Leaf-list entries can be created and deleted, but not modified,
through <edit-config>, by using the "operation" attribute in the through <edit-config>, by using the "operation" attribute in the
leaf-list entry's XML element. leaf-list entry's XML element.
In an "ordered-by user" leaf-list, the attributes "insert" and In an "ordered-by user" leaf-list, the attributes "insert" and
"value" in the YANG XML namespace (Section 5.3.1) can be used to "value" in the YANG XML namespace (Section 5.3.1) can be used to
control where in the leaf-list the entry is inserted. These can be control where in the leaf-list the entry is inserted. These can be
used during "create" operations to insert a new leaf-list entry, or used during "create" operations to insert a new leaf-list entry, or
during "merge" or "replace" operations to insert a new leaf-list during "merge" or "replace" operations to insert a new leaf-list
skipping to change at page 67, line 43 skipping to change at page 67, line 45
which covers the entire leaf-list, the leaf-list order is the same as which covers the entire leaf-list, the leaf-list order is the same as
the order of the XML elements in the request. the order of the XML elements in the request.
When a NETCONF server processes an <edit-config> request, the When a NETCONF server processes an <edit-config> request, the
elements of procedure for a leaf-list node are: elements of procedure for a leaf-list node are:
If the operation is "merge" or "replace" the leaf-list entry is If the operation is "merge" or "replace" the leaf-list entry is
created if it does not exist. created if it does not exist.
If the operation is "create" the leaf-list entry is created if it If the operation is "create" the leaf-list entry is created if it
does not exist. does not exist. If the leaf-list entry already exists, a
"data-exists" error is returned.
If the operation is "delete" the entry is deleted from the leaf- If the operation is "delete" the entry is deleted from the leaf-
list if it exists. list if it exists. If the leaf-list entry does not exist, a
"data-missing" error is returned.
7.7.8. Usage Example 7.7.8. Usage Example
leaf-list allow-user { leaf-list allow-user {
type string; type string;
description "A list of user name patterns to allow"; description "A list of user name patterns to allow";
} }
A corresponding XML instance example: A corresponding XML instance example:
<allow-user>alice</allow-user> <allow-user>alice</allow-user>
<allow-user>bob</allow-user> <allow-user>bob</allow-user>
To create a new element in the list: To create a new element in this list, using the default <edit-config>
operation "merge":
<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 69, line 29 skipping to change at page 69, line 29
yang:value="3des-cbc">blowfish-cbc</cipher> yang:value="3des-cbc">blowfish-cbc</cipher>
</ssh> </ssh>
</services> </services>
</system> </system>
</config> </config>
</edit-config> </edit-config>
</rpc> </rpc>
7.8. The list Statement 7.8. The list Statement
The "list" statement is used to define interior nodes in the schema The "list" statement is used to define an interior data node in the
tree. A list node may exist in multiple instances in the data tree. schema tree. A list node may exist in multiple instances in the data
Each such instance is known as a list entry. The "list" statement tree. Each such instance is known as a list entry. The "list"
takes one argument which is an identifier, followed by a block of statement takes one argument which is an identifier, followed by a
substatements that holds detailed list information. block of substatements that holds detailed list information.
A list entry is uniquely identified by the values of the list's keys, A list entry is uniquely identified by the values of the list's keys,
if defined. if defined.
A list is similar to a table where each list entry is a row in the A list is similar to a table where each list entry is a row in the
table. table.
7.8.1. The list's Substatements 7.8.1. The list's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
skipping to change at page 72, line 46 skipping to change at page 72, line 46
7.8.4. The list's Child Node Statements 7.8.4. The list's Child Node Statements
Within a list, the "container", "leaf", "list", "leaf-list", "uses", Within a list, the "container", "leaf", "list", "leaf-list", "uses",
"choice", and "anyxml" statements can be used to define child nodes "choice", and "anyxml" statements can be used to define child nodes
to the list. to the list.
7.8.5. XML Mapping Rules 7.8.5. XML Mapping Rules
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 local name is the list's identifier, and
namespace is the module's XML namespace. its namespace is the module's XML namespace (see Section 7.1.3).
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. If the list defines RPC input or list element, after the keys. If the list defines RPC input or
output parameters, the subelements are encoded in the same order as output parameters, the subelements are encoded in the same order as
they are defined within the list statement. Otherwise, the they are defined within the list statement. Otherwise, the
subelements are encoded in any order. subelements are encoded in any order.
The XML elements representing list entries MUST appear in the order The XML elements representing list entries MUST appear in the order
specified by the user if the list is "ordered-by user", otherwise the specified by the user if the list is "ordered-by user", otherwise the
order is implementation-dependent. The XML elements representing order is implementation-dependent. The XML elements representing
list entries MAY be interleaved with other sibling elements, unless list entries MAY be interleaved with other sibling elements, unless
the list defines RPC input or output parameters. the list defines RPC input or output parameters.
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
the YANG XML namespace (Section 5.3.1) can be used to control where the YANG XML namespace (Section 5.3.1) can be used to control where
in the list the entry is inserted. These can be used during "create" in the list the entry is inserted. These can be used during "create"
skipping to change at page 73, line 48 skipping to change at page 73, line 48
defaults to "last". defaults to "last".
If several entries in an "ordered-by user" list are modified in the If several entries in an "ordered-by user" list are modified in the
same <edit-config> request, the entries are modified one at the time, same <edit-config> request, the entries are modified one at the time,
in the order of the XML elements in the request. in the order of the XML elements in the request.
In a <copy-config>, or an <edit-config> with a "replace" operation In a <copy-config>, or an <edit-config> with a "replace" operation
which covers the entire list, the list entry order is the same as the which covers the entire list, the list entry order is the same as the
order of the XML elements in the request. order of the XML elements in the request.
When a NETCONF server processes an <edit-config> request, the
elements of procedure for a list node are:
If the operation is "merge" or "replace" the list entry is created
if it does not exist.
If the operation is "create" the list entry is created if it does
not exist. If the list entry already exists, a "data-exists"
error is returned.
If the operation is "delete" the entry is deleted from the list if
it exists. If the list entry does not exist, a "data-missing"
error is returned.
7.8.7. Usage Example 7.8.7. Usage Example
Given the following list: Given the following list:
list user { list user {
key "name"; key "name";
config true; config true;
description "This is a list of users in the system."; description "This is a list of users in the system.";
leaf name { leaf name {
skipping to change at page 79, line 27 skipping to change at page 79, line 43
| 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 |
| uses | 7.12 | 0..n | | uses | 7.12 | 0..n |
| when | 7.19.5 | 0..1 | | when | 7.19.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.9.3. The choice's default Statement 7.9.3. The choice's default Statement
The "default" statement indicates if a case should be considered as The "default" statement indicates if a case should be considered as
the default if no child nodes from any of the choice's cases exists. the default if no child nodes from any of the choice's cases exist.
The argument is the identifier of the "case" statement. If the The argument is the identifier of the "case" statement. If the
"default" statement is missing, there is no default case. "default" statement is missing, there is no default case.
The "default" statement MUST NOT be present on choices where The "default" statement MUST NOT be present on choices where
"mandatory" is true. "mandatory" is true.
The default case is only important when considering the default The default case is only important when considering the default
values of nodes under the cases. The default values for nodes under values of nodes under the cases. The default values for nodes under
the default case are used if none of the nodes under any of the cases the default case are used if none of the nodes under any of the cases
are present. are present.
skipping to change at page 81, line 12 skipping to change at page 81, line 33
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.9.5. XML Mapping Rules 7.9.5. XML Mapping Rules
The choice and case nodes are not visible in XML. The choice and case nodes are not visible in XML.
The child nodes of the selected "case" statement MUST be encoded in The child nodes of the selected "case" statement MUST be encoded in
the same order as they are defined in the "case" statement if they the same order as they are defined in the "case" statement if they
are part of a RPC input or output parameter definition. Otherwise, are part of a RPC input or output parameter definition. Otherwise,
the subelements are be encoded in any order. the subelements are encoded in any order.
7.9.6. NETCONF <edit-config> operations 7.9.6. NETCONF <edit-config> Operations
Since only one of the choice's cases can be valid at any time, the Since only one of the choice's cases can be valid at any time, the
creation of a node from one case implicitly deletes all nodes from creation of a node from one case implicitly deletes all nodes from
all other cases. If an <edit-config> operation creates a node, the all other cases. If an <edit-config> operation creates a node from a
NETCONF server will delete any existing nodes that are defined in case, the NETCONF server will delete any existing nodes that are
other cases inside the choice. defined in other cases inside the choice.
7.9.7. Usage Example 7.9.7. Usage Example
Given the following choice: Given the following choice:
container protocol { container protocol {
choice name { choice name {
case a { case a {
leaf udp { leaf udp {
type empty; type empty;
skipping to change at page 83, line 22 skipping to change at page 83, line 32
| if-feature | 7.18.2 | 0..n | | if-feature | 7.18.2 | 0..n |
| mandatory | 7.6.5 | 0..1 | | mandatory | 7.6.5 | 0..1 |
| must | 7.5.3 | 0..n | | must | 7.5.3 | 0..n |
| reference | 7.19.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.19.2 | 0..1 |
| when | 7.19.5 | 0..1 | | when | 7.19.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.10.2. XML Mapping Rules 7.10.2. XML Mapping Rules
An anyxml node is encoded as an XML element. The element's name is An anyxml node is encoded as an XML element. The element's local
the anyxml's identifier, and its XML namespace is the module's XML name is the anyxml's identifier, and its namespace is the module's
namespace. The value of the anyxml node is encoded as XML content of XML namespace (see Section 7.1.3). The value of the anyxml node is
this element. encoded as XML content of this element.
Note that any prefixes used in the encoding are local to each Note that any prefixes used in the encoding are local to each
instance encoding. This means that the same XML may be encoded instance encoding. This means that the same XML may be encoded
differently by different implementations. differently by different implementations.
7.10.3. NETCONF <edit-config> operations 7.10.3. NETCONF <edit-config> Operations
An anyxml node is treated as an opaque chunk of data. This data can An anyxml node is treated as an opaque chunk of data. This data can
be modified in its entirety only. be modified in its entirety only.
Any "operation" attributes present on subelements of an anyxml node Any "operation" attributes present on subelements of an anyxml node
are ignored by the NETCONF server. are ignored by the NETCONF server.
When a NETCONF server processes an <edit-config> request, the When a NETCONF server processes an <edit-config> request, the
elements of procedure for the anyxml node are: elements of procedure for the anyxml node are:
If the operation is "merge", the node is created if it does not If the operation is "merge" or "replace", the node is created if
exist, and its value is set to the XML content of the anyxml node it does not exist, and its value is set to the XML content of the
found in the XML RPC data. anyxml node found in the XML RPC data.
If the operation is "replace", the node is created if it does not
exist, and its value is set to the XML content of the anyxml node
found in the XML RPC data.
If the operation is "create" the node is created if it does not If the operation is "create" the node is created if it does not
exist, and its value is set to the XML content of the anyxml node exist, and its value is set to the XML content of the anyxml node
found in the XML RPC data. found in the XML RPC data. If the node already exists, a
"data-exists" error is returned.
If the operation is "delete" the node is deleted if it exists. If the operation is "delete" the node is deleted if it exists. If
the node does not exist, a "data-missing" error is returned.
7.10.4. Usage Example 7.10.4. Usage Example
Given the following anyxml statement: Given the following anyxml statement:
anyxml data; anyxml data;
The following are two valid encodings of the same anyxml value: The following are two valid encodings of the same anyxml value:
<data xmlns:if="http://example.com/ns/interface"> <data xmlns:if="http://example.com/ns/interface">
skipping to change at page 86, line 27 skipping to change at page 87, line 22
| if-feature | 7.18.2 | 0..n | | if-feature | 7.18.2 | 0..n |
| refine | 7.12.2 | 0..1 | | refine | 7.12.2 | 0..1 |
| reference | 7.19.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.19.2 | 0..1 |
| when | 7.19.5 | 0..1 | | when | 7.19.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.12.2. The refine Statement 7.12.2. The refine Statement
Some of the properties of each node in the grouping can be refined Some of the properties of each node in the grouping can be refined
with the "refine" statement. The argument is a a string which with the "refine" statement. The argument is a string which
identifies a node in the grouping. This node is called the refine's identifies a node in the grouping. This node is called the refine's
target node. If a node in the grouping is not present as target node target node. If a node in the grouping is not present as target node
of a refine statement, it is not refined, and thus used exactly as it of a refine statement, it is not refined, and thus used exactly as it
was defined in the grouping. was defined in the grouping.
The argument string is a descendant schema node identifier (see The argument string is a descendant schema node identifier (see
Section 6.5). Section 6.5).
The following refinements can be done: The following refinements can be done:
skipping to change at page 88, line 29 skipping to change at page 89, line 24
container http-server { container http-server {
uses acme:address; uses acme:address;
leaf ip { // illegal - same identifier "ip" used twice leaf ip { // illegal - same identifier "ip" used twice
type string; type string;
} }
} }
7.13. The rpc Statement 7.13. The rpc Statement
The "rpc" statement is used to define a NETCONF RPC method. It takes The "rpc" statement is used to define a NETCONF RPC operation. It
one argument, which is an identifier, followed by a block of takes one argument, which is an identifier, followed by a block of
substatements that holds detailed rpc information. This argument is substatements that holds detailed rpc information. This argument is
the name of the RPC, and is used as the element name directly under the name of the RPC, and is used as the element name directly under
the <rpc> element, as designated by the substitution group the <rpc> element, as designated by the substitution group
"rpcOperation" in [RFC4741]. "rpcOperation" in [RFC4741].
The "rpc" statement defines an rpc node in the schema tree. Under The "rpc" statement defines an rpc node in the schema tree. Under
the rpc node, an input node with the name "input", and an output node the rpc node, an input node with the name "input", and an output node
with the name "output" are also defined. The nodes "input" and with the name "output" are also defined. The nodes "input" and
"output" are defined in the module's namespace. "output" are defined in the module's namespace.
skipping to change at page 89, line 23 skipping to change at page 90, line 23
| input | 7.13.2 | 0..1 | | input | 7.13.2 | 0..1 |
| output | 7.13.3 | 0..1 | | output | 7.13.3 | 0..1 |
| reference | 7.19.4 | 0..1 | | reference | 7.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 |
+--------------+---------+-------------+ +--------------+---------+-------------+
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 operation. It does not take an argument. The
substatements to "input" define nodes under the RPC's input node. substatements to "input" define nodes under the RPC's input node.
If a leaf in the input tree has a "mandatory" statement with the If a leaf in the input tree has a "mandatory" statement with the
value "true", the leaf MUST be present in a NETCONF RPC invocation. value "true", the leaf MUST be present in a NETCONF RPC invocation.
Otherwise, the server MUST return a "missing-element" error. Otherwise, the server MUST return a "missing-element" error.
If a leaf in the input tree has a default value, the NETCONF server If a leaf in the input tree has a default value, the NETCONF server
MUST use this value in the same cases as described in Section 7.6.1. MUST use this value in the same cases as described in Section 7.6.1.
In these cases, the server MUST operationally behave as if the leaf In these cases, the server MUST operationally behave as if the leaf
was present in the NETCONF RPC invocation with the default value as was present in the NETCONF RPC invocation with the default value as
its value. its value.
If a "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,
is ignored. the "config" statement is ignored.
If any node has a "when" statement which would evaluate to false, If any node has a "when" statement which would evaluate to false,
then this node MUST NOT be present in the input tree. 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 |
skipping to change at page 90, line 24 skipping to change at page 91, line 24
| leaf | 7.6 | 0..n | | leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n | | leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n | | list | 7.8 | 0..n |
| 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 operation. It does not take an argument. The
substatements to "output" define nodes under the RPC's output node. substatements to "output" define nodes under the RPC's output node.
If a leaf in the output tree has a "mandatory" statement with the If a leaf in the output tree has a "mandatory" statement with the
value "true", the leaf MUST be present in a NETCONF RPC reply. value "true", the leaf MUST be present in a NETCONF RPC reply.
If a leaf in the output tree has a default value, the NETCONF client If a leaf in the output tree has a default value, the NETCONF client
MUST use this value in the same cases as described in Section 7.6.1. MUST use this value in the same cases as described in Section 7.6.1.
In these cases, the client MUST operationally behave as if the leaf In these cases, the client MUST operationally behave as if the leaf
was present in the NETCONF RPC reply with the default value as its was present in the NETCONF RPC reply with the default value as its
value. value.
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. the "config" statement is ignored.
If any node has a "when" statement which would evaluate to false, If any node has a "when" statement which would evaluate to false,
then this node MUST NOT be present in the output tree. 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 |
skipping to change at page 91, line 24 skipping to change at page 92, line 24
| leaf | 7.6 | 0..n | | leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n | | leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n | | list | 7.8 | 0..n |
| typedef | 7.3 | 0..n | | typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n | | uses | 7.12 | 0..n |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.13.4. XML Mapping Rules 7.13.4. XML Mapping Rules
An rpc node is encoded as a child XML element to the <rpc> element An rpc node is encoded as a child XML element to the <rpc> element
defined in [RFC4741]. The element's name is the rpc's identifier, defined in [RFC4741]. The element's local name is the rpc's
and its XML namespace is the module's XML namespace. identifier, and its namespace is the module's XML namespace (see
Section 7.1.3).
Input parameters are encoded as child XML elements to the rpc node's Input parameters are encoded as child XML elements to the rpc node's
XML element, in the same order as they are defined within the input XML element, in the same order as they are defined within the input
statement. statement.
If the RPC method invocation succeeded, and no output parameters are If the RPC operation invocation succeeded, and no output parameters
returned, the <rpc-reply> contains a single <ok/> element defined in are returned, the <rpc-reply> contains a single <ok/> element defined
[RFC4741]. If output parameters are returned, they are encoded as in [RFC4741]. If output parameters are returned, they are encoded as
child elements to the <rpc-reply> element defined in [RFC4741], in child elements to the <rpc-reply> element defined in [RFC4741], in
the same order as they are defined within the output statement. the same order as they are defined within the output statement.
7.13.5. Usage Example 7.13.5. Usage Example
The following example defines an RPC method: The following example defines an RPC operation:
module rock { module rock {
namespace "http://example.net/rock"; namespace "http://example.net/rock";
prefix "rock"; prefix "rock";
rpc rock-the-house { rpc rock-the-house {
input { input {
leaf zip-code { leaf zip-code {
type string; type string;
} }
skipping to change at page 92, line 28 skipping to change at page 93, line 30
</rpc-reply> </rpc-reply>
7.14. The notification Statement 7.14. The notification Statement
The "notification" statement is used to define a NETCONF The "notification" statement is used to define a NETCONF
notification. It takes one argument, which is an identifier, notification. It takes one argument, which is an identifier,
followed by a block of substatements that holds detailed notification followed by a block of substatements that holds detailed notification
information. The "notification" statement defines a notification information. The "notification" statement defines a notification
node in the schema tree. node in the schema tree.
If a container in the notification tree has a "presence" statement,
the container need not be present in a NETCONF notification.
If a leaf in the notification tree has a "mandatory" statement with If a leaf in the notification tree has a "mandatory" statement with
the value "true", the leaf MUST be present in a NETCONF notification. the value "true", the leaf MUST be present in a NETCONF notification.
If a leaf in the notification tree has a default value, the NETCONF If a leaf in the notification tree has a default value, the NETCONF
client MUST use this value in the same cases as described in client MUST use this value in the same cases as described in
Section 7.6.1. In these cases, the client MUST operationally behave Section 7.6.1. In these cases, the client MUST operationally behave
as if the leaf was present in the NETCONF notification with the as if the leaf was present in the NETCONF notification with the
default value as its value. default value as its value.
If a "config" statement is present for any node in the notification If a "config" statement is present for any node in the notification
tree, it is ignored. tree, the "config" statement is ignored.
7.14.1. The notification's Substatements 7.14.1. The notification's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anyxml | 7.10 | 0..n | | anyxml | 7.10 | 0..n |
| 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 93, line 29 skipping to change at page 94, line 29
| 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 Mapping Rules 7.14.2. XML Mapping Rules
A notification node is encoded as a child XML element to the A notification node is encoded as a child XML element to the
<notification> element defined in NETCONF Event Notifications <notification> element defined in NETCONF Event Notifications
[RFC5277]. The element's name is the notification's identifier, and [RFC5277]. The element's local name is the notification's
its XML namespace is the module's XML namespace. identifier, and its namespace is the module's XML namespace (see
Section 7.1.3).
7.14.3. Usage Example 7.14.3. Usage Example
The following example defines a notification: The following example defines a notification:
module event { module event {
namespace "http://example.com/event"; namespace "http://example.com/event";
prefix "ev"; prefix "ev";
skipping to change at page 96, line 39 skipping to change at page 97, line 39
augment "/if:interfaces/if:ifEntry" { augment "/if:interfaces/if:ifEntry" {
when "if:ifType='ds0'"; when "if:ifType='ds0'";
leaf ds0ChannelNumber { leaf ds0ChannelNumber {
type ChannelNumber; type ChannelNumber;
} }
} }
A corresponding XML instance example: A corresponding XML instance example:
<interfaces xmlns="http://example.com/schema/interfaces" <interfaces xmlns="http://example.com/schema/interfaces"
xmlns:ds0="http://example.com/schema/ds0" xmlns:ds0="http://example.com/schema/ds0">
<ifEntry> <ifEntry>
<ifIndex>1</ifIndex> <ifIndex>1</ifIndex>
<ifDescr>Flintstone Inc Ethernet A562</ifDescr> <ifDescr>Flintstone Inc Ethernet A562</ifDescr>
<ifType>ethernetCsmacd</ifType> <ifType>ethernetCsmacd</ifType>
<ifMtu>1500</ifMtu> <ifMtu>1500</ifMtu>
</ifEntry> </ifEntry>
<ifEntry> <ifEntry>
<ifIndex>2</ifIndex> <ifIndex>2</ifIndex>
<ifDescr>Flintstone Inc DS0</ifDescr> <ifDescr>Flintstone Inc DS0</ifDescr>
<ifType>ds0</ifType> <ifType>ds0</ifType>
skipping to change at page 99, line 52 skipping to change at page 100, line 52
The statement's argument is an identifier that is the new keyword for The statement's argument is an identifier that is the new keyword for
the extension and must be followed by a block of substatements that the extension and must be followed by a block of substatements that
holds detailed extension information. The purpose of the extension holds detailed extension information. The purpose of the extension
statement is to define a keyword, so that it can be imported and used statement is to define a keyword, so that it can be imported and used
by other modules. by other modules.
The extension can be used like a normal YANG statement, with the The extension can be used like a normal YANG statement, with the
statement name followed by an argument if one is defined by the statement name followed by an argument if one is defined by the
extension, and an optional block of substatements. The statement's extension, and an optional block of substatements. The statement's
name is created by combining the the prefix of the module in which name is created by combining the prefix of the module in which the
the extension was defined, a colon (":"), and the extension's extension was defined, a colon (":"), and the extension's keyword,
keyword, with no interleaving whitespace. The substatements of an with no interleaving whitespace. The substatements of an extension
extension are defined by the extension, using some mechanism outside are defined by the extension, using some mechanism outside the scope
the scope of this specification. Syntactically, the substatements of this specification. Syntactically, the substatements MUST be YANG
MUST be core YANG statements, or also defined using "extension" statements, or also defined using "extension" statements. YANG
statements. Core YANG statements in extensions MUST follow the statements in extensions MUST follow the syntactical rules in
syntactical rules in Section 12. Section 12.
7.17.1. The extension's Substatements 7.17.1. The extension's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| argument | 7.17.2 | 0..1 | | argument | 7.17.2 | 0..1 |
| description | 7.19.3 | 0..1 | | description | 7.19.3 | 0..1 |
| reference | 7.19.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.19.2 | 0..1 |
skipping to change at page 103, line 34 skipping to change at page 104, line 34
module's prefix. Otherwise a feature with the matching name MUST be module's prefix. Otherwise a feature with the matching name MUST be
defined 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 a 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
identifies the node in the schema tree where a deviation from the identifies the node in the schema tree where a deviation from the
module occurs. This node is called the deviation's target node. The module occurs. This node is called the deviation's target node. The
contents of the deviation statement give details about the deviation. contents of the deviation statement give details about the deviation.
The argument string is an absolute schema node identifier (see The argument string is an absolute schema node identifier (see
Section 6.5). Section 6.5).
Deviations define the way a device or class of devices deviate from Deviations define the way a device or class of devices deviate from a
the standard. This means that deviations MUST never be part of a standard. This means that deviations MUST never be part of a
published standard, since they are the mechanism for learning how published standard, since they are the mechanism for learning how
implementations vary from the standards. implementations vary from the standards.
Device deviations are strongly discouraged and SHOULD only be used as Device deviations are strongly discouraged and SHOULD only be used as
a last resort. Telling the application how a device fails to follow a last resort. Telling the application how a device fails to follow
the standard is no substitute for implementing the standard a standard is no substitute for implementing the standard correctly.
correctly.
However in some cases a particular device may not have the hardware However in some cases a particular device may not have the hardware
or software ability to support parts of a standard module. When this or software ability to support parts of a standard module. When this
occurs, the device makes a choice to treat attempts to configure occurs, the device makes a choice to treat attempts to configure
unsupported parts of the module as either an error that is reported unsupported parts of the module as either an error that is reported
back to the unsuspecting application, or ignore that incoming back to the unsuspecting application, or ignore that incoming
requests. Neither choice is acceptable. requests. Neither choice is acceptable.
Instead, YANG allows devices to document portions of the base module Instead, YANG allows devices to document portions of a base module
which are not supported or supported but with different syntax, by which are not supported or supported but with different syntax, by
using the "deviation" statement. using the "deviation" statement.
7.18.3.1. The deviation's Substatements 7.18.3.1. The deviation's Substatements
+--------------+----------+-------------+ +--------------+----------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+----------+-------------+ +--------------+----------+-------------+
| description | 7.19.3 | 0..1 | | description | 7.19.3 | 0..1 |
| deviate | 7.18.3.2 | 1..n | | deviate | 7.18.3.2 | 1..n |
skipping to change at page 104, line 46 skipping to change at page 105, line 44
properties to add are identified as a substatement to the "deviate" properties to add are identified as a substatement to the "deviate"
statement. If the property can only appear once, the property MUST statement. If the property can only appear once, the property MUST
NOT exist in the target node. NOT exist in the target node.
The argument "replace" replaces properties of the target node. The The argument "replace" replaces properties of the target node. The
properties to replace are identified by substatements to the properties to replace are identified by substatements to the
"deviate" statement. The property to replace MUST exist in the "deviate" statement. The property to replace MUST exist in the
target node. target node.
The argument "delete" deletes properties from the target node. The The argument "delete" deletes properties from the target node. The
properties to delete are identified by substatement to "delete". The properties to delete are identified by substatement to the "delete"
substatement's keyword MUST match a corresponding keyword in the statement. The substatement's keyword MUST match a corresponding
target node, and the argument's string MUST be equal to the keyword in the target node, and the argument's string MUST be equal
corresponding keyword's argument string in the target node. to the corresponding keyword's argument string in the target node.
The deviates's Substatements The deviates's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| config | 7.19.1 | 0..1 | | config | 7.19.1 | 0..1 |
| default | 7.6.4 | 0..1 | | default | 7.6.4 | 0..1 |
| mandatory | 7.6.5 | 0..1 | | mandatory | 7.6.5 | 0..1 |
| max-elements | 7.7.4 | 0..1 | | max-elements | 7.7.4 | 0..1 |
skipping to change at page 107, line 48 skipping to change at page 108, line 48
The XPath expression is conceptually evaluated in the following The XPath expression is conceptually evaluated in the following
context, in addition to the definition in Section 6.4.1: context, in addition to the definition in Section 6.4.1:
o If the "when" statement is a child of an "augment" statement, then o If the "when" statement is a child of an "augment" statement, then
the context node is the augment's target node in the data tree, if the context node is the augment's target node in the data tree, if
the target node is a data node. Otherwise, the context node is the target node is a data node. Otherwise, the context node is
the closest ancestor node to the target node which is also a data the closest ancestor node to the target node which is also a data
node. node.
o If the "when" statement is a child of a "choice" or "case" o If the "when" statement is a child of a "uses", "choice", or
statement, then the context node is the closest ancestor node to "case" statement, then the context node is the closest ancestor
the "choice" or "case" node which is also a data node. node to the "uses", "choice", or "case" node which is also a data
node.
o If the "when" statement is a child of any other data definition o If the "when" statement is a child of any other data definition
statement, the context node is the data definition's node in the statement, the context node is the data definition's node in the
data tree. data tree.
o The accessible tree is made up of all nodes in the data tree, and o The accessible tree is made up of all nodes in the data tree, and
all leafs with default values in use (see Section 7.6.1). all leafs with default values in use (see Section 7.6.1).
The accessible tree depends on the context node: The accessible tree depends on the context node:
skipping to change at page 108, line 30 skipping to change at page 109, line 30
data on the device, and the <running/> datastore. The XPath root data on the device, and the <running/> datastore. The XPath root
node has all top-level data nodes in all modules as children. node has all top-level data nodes in all modules as children.
o If the context node represents notification content, the tree is o If the context node represents notification content, the tree is
the notification XML instance document. The XPath root node has the notification XML instance document. The XPath root node has
the element representing the notification being defined as the the element representing the notification being defined as the
only child. only child.
o If the context node represents RPC input parameters, the tree is o If the context node represents RPC input parameters, the tree is
the RPC XML instance document. The XPath root node has the the RPC XML instance document. The XPath root node has the
element representing the RPC method being defined as the only element representing the RPC operation 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 "when" statement can very well be implemented with
written code. specially written code.
8. Constraints 8. Constraints
8.1. Constraints on Data 8.1. Constraints on Data
Several YANG statements define constraints on valid data. These Several YANG statements define constraints on valid data. These
constraints are enforced in different ways, depending on what type of constraints are enforced in different ways, depending on what type of
data the statement defines. data the statement defines.
o If the constraint is defined on configuration data, it MUST be o If the constraint is defined on configuration data, it MUST be
true in a valid configuration data tree. true in a valid configuration data tree.
o If the constraint is defined on state data, it MUST be true in a o If the constraint is defined on state data, it MUST be true in a
reply to the <get> command. reply to a <get> operation without a filter.
o If the constraint is defined on notification content, it MUST be o If the constraint is defined on notification content, it MUST be
true in any notification instance. true in any notification instance.
o If the constraint is defined on RPC input parameters, it MUST be o If the constraint is defined on RPC input parameters, it MUST be
true in an invocation of the RPC method. true in an invocation of the RPC operation.
o If the constraint is defined on RPC output parameters, it MUST be o If the constraint is defined on RPC output parameters, it MUST be
true in the RPC reply. true in the RPC reply.
8.2. Hierarchy of Constraints 8.2. Hierarchy of Constraints
Conditions on parent nodes affect constraints on child nodes as a Conditions on parent nodes affect constraints on child nodes as a
natural consequence of the hierarchy of nodes. "must", "mandatory", natural consequence of the hierarchy of nodes. "must", "mandatory",
"min-elements", and "max-elements" constraints are not enforced if "min-elements", and "max-elements" constraints are not enforced if
the parent node has a "when" or "if-feature" property that is not the parent node has a "when" or "if-feature" property that is not
skipping to change at page 111, line 20 skipping to change at page 112, line 20
o Insert requests with "before" or "after" parameters which do not o Insert requests with "before" or "after" parameters which do not
exist. exist.
During <edit-config> processing: During <edit-config> processing:
o If the NETCONF operation creates data nodes under a "choice", any o If the NETCONF operation creates data nodes under a "choice", any
existing nodes from other "case" branches are deleted by the existing nodes from other "case" branches are deleted by the
server. server.
o If the NETCONF operation modifies a data node such that any node's o If the NETCONF operation modifies a data node such that any node's
"when" expression becomes false, then that node is deleted by the "when" expression becomes false, then the node with the "when"
server. expression is deleted by the server.
8.3.3. Validation 8.3.3. Validation
When datastore processing is complete, the final contents MUST obey When datastore processing is complete, the final contents MUST obey
all validation constraints. This validation processing is performed all validation constraints. This validation processing is performed
at differing time according to the datastore. If the datastore is at differing time according to the datastore. If the datastore is
<running/> or <startup/>, these constraints MUST be enforced at the <running/> or <startup/>, these constraints MUST be enforced at the
end of the <edit-config> or <copy-config> operation. If the end of the <edit-config> or <copy-config> operation. If the
datastore is <candidate/>, the constraint enforcement is delayed datastore is <candidate/>, the constraint enforcement is delayed
until a <commit> or <validate> operation. until a <commit> or <validate> operation.
skipping to change at page 116, line 47 skipping to change at page 118, line 7
| 13 | -922337.2036854775808 | 922337.2036854775807 | | 13 | -922337.2036854775808 | 922337.2036854775807 |
| 14 | -92233.72036854775808 | 92233.72036854775807 | | 14 | -92233.72036854775808 | 92233.72036854775807 |
| 15 | -9223.372036854775808 | 9223.372036854775807 | | 15 | -9223.372036854775808 | 9223.372036854775807 |
| 16 | -922.3372036854775808 | 922.3372036854775807 | | 16 | -922.3372036854775808 | 922.3372036854775807 |
| 17 | -92.23372036854775808 | 92.23372036854775807 | | 17 | -92.23372036854775808 | 92.23372036854775807 |
| 18 | -9.223372036854775808 | 9.223372036854775807 | | 18 | -9.223372036854775808 | 9.223372036854775807 |
+----------------+-----------------------+----------------------+ +----------------+-----------------------+----------------------+
9.3.5. Usage Example 9.3.5. Usage Example
type decimal64 { typedef my-decimal {
fraction-digits 2; type decimal64 {
range "1 .. 3.14 | 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.
string = *char string = *char
char = %x9 / %xA / %xD / %x20-DFFF / %xE000-FFFD / char = %x9 / %xA / %xD / %x20-DFFF / %xE000-FFFD /
%x10000-10FFFF %x10000-10FFFF
9.4.1. Lexicographic Representation 9.4.1. Lexicographic Representation
A string value is lexicographically represented as character data in A string value is lexicographically represented as character data in
the XML instance documents. the XML instance documents.
9.4.2. Canonical Form 9.4.2. Canonical Form
skipping to change at page 118, line 45 skipping to change at page 120, line 10
type my-base-str-type { type my-base-str-type {
// illegal length refinement // illegal length refinement
length "1..999"; length "1..999";
} }
9.4.6. The pattern Statement 9.4.6. The pattern Statement
The "pattern" statement, which is an optional substatement to the The "pattern" statement, which is an optional substatement to the
"type" statement, takes as an argument a regular expression string, "type" statement, takes as an argument a regular expression string,
as defined in [XSD-TYPES]. It is used to restrict the built-in type as defined in [XSD-TYPES]. It is used to restrict the built-in type
"string", or types derived from "string", to values that completely "string", or types derived from "string", to values that matches the
matches the pattern. pattern.
If the type has multiple "pattern" statements, the expressions are If the type has multiple "pattern" statements, the expressions are
ANDed together, i.e., all such expressions have to match. ANDed together, i.e., all such expressions have to match.
If a pattern restriction is applied to an already pattern restricted If a pattern restriction is applied to an already pattern restricted
type, values must match all patterns in the base type, in addition to type, values must match all patterns in the base type, in addition to
the new patterns. the new patterns.
9.4.6.1. The pattern's Substatements 9.4.6.1. The pattern's Substatements
skipping to change at page 121, line 35 skipping to change at page 122, line 35
If the enum sub-statement is the first one defined, the assigned If the enum sub-statement is the first one defined, the assigned
value is zero (0), otherwise the assigned value is one greater than value is zero (0), otherwise the assigned value is one greater than
the current highest enum value. the current highest enum value.
If the current highest value is equal to 2147483647, then an enum If the current highest value is equal to 2147483647, then an enum
value MUST be specified for enum sub-statements following the one value MUST be specified for enum sub-statements following the one
with the current highest value. with the current highest value.
9.6.5. Usage Example 9.6.5. Usage Example
type enumeration {
enum enabled {
value 1;
}
enum disabled {
value 2;
}
}
leaf myenum { leaf myenum {
type enumeration { type enumeration {
enum zero; enum zero;
enum one; enum one;
enum seven { enum seven {
value 7; value 7;
} }
} }
} }
skipping to change at page 123, line 36 skipping to change at page 124, line 25
assigned. If the bit sub-statement is the first one defined, the assigned. If the bit sub-statement is the first one defined, the
assigned value is zero (0), otherwise the assigned value is one assigned value is zero (0), otherwise the assigned value is one
greater than the current highest bit position. greater than the current highest bit position.
If the current highest bit position value is equal to 4294967295, If the current highest bit position value is equal to 4294967295,
then a position value MUST be specified for bit sub-statements then a position value MUST be specified for bit sub-statements
following the one with the current highest position value. following the one with the current highest position value.
9.7.5. Usage Example 9.7.5. Usage Example
Given the following type: Given the following leaf:
leaf mybits { leaf mybits {
type bits { type bits {
bit disable-nagle { bit disable-nagle {
position 0; position 0;
} }
bit auto-sense-speed { bit auto-sense-speed {
position 1; position 1;
} }
bit 10-Mb-only { bit 10-Mb-only {
skipping to change at page 132, line 39 skipping to change at page 133, line 39
type union { type union {
type int32; type int32;
type enumeration { type enumeration {
enum "unbounded"; enum "unbounded";
} }
} }
9.12.1. Restrictions 9.12.1. Restrictions
A union cannot be restricted. However, each member type can be A union cannot be restricted. However, each member type can be
restricted, based on the rules defined in Section 9 chapter. restricted, based on the rules defined in Section 9.
9.12.2. Lexicographic Representation 9.12.2. Lexicographic Representation
The lexicographical representation of an union is a value that The lexicographical representation of an union is a value that
corresponds to the representation of any one of the member types. corresponds to the representation of any one of the member types.
9.12.3. Canonical Form 9.12.3. Canonical Form
The canonical form of a union value is the same as the canonical form The canonical form of a union value is the same as the canonical form
of the member type of the value. of the member type of the value.
skipping to change at page 136, line 14 skipping to change at page 137, line 14
10. Updating a Module 10. Updating a Module
As experience is gained with a module, it may be desirable to revise As experience is gained with a module, it may be desirable to revise
that module. However, changes are not allowed if they have any that module. However, changes are not allowed if they have any
potential to cause interoperability problems between a client using potential to cause interoperability problems between a client using
an original specification and a server using an updated an original specification and a server using an updated
specification. specification.
For any published change, a new "revision" statement (Section 7.1.9) For any published change, a new "revision" statement (Section 7.1.9)
SHOULD be included in front of the existing revision statements. MUST be included in front of the existing revision statements. If
Furthermore, any necessary changes MUST be applied to any meta data there are no existing revision statements, then one MUST be added to
statements, including the "organization" and "contact" statements identify the new revision. Furthermore, any necessary changes MUST
(Section 7.1.7, Section 7.1.8). be applied to any meta data statements, including the "organization"
and "contact" statements (Section 7.1.7, Section 7.1.8).
Note that definitions contained in a module are available to be Note that definitions contained in a module are available to be
imported by any other module, and are referenced in "import" imported by any other module, and are referenced in "import"
statements via the module name. Thus, a module name MUST NOT be statements via the module name. Thus, a module name MUST NOT be
changed. Furthermore, the "namespace" statement MUST NOT be changed, changed. Furthermore, the "namespace" statement MUST NOT be changed,
since all XML elements are encoded in the namespace. since all XML elements are encoded in the namespace.
Obsolete definitions MUST NOT be removed from modules since their Obsolete definitions MUST NOT be removed from modules since their
identifiers may still be referenced by other modules. identifiers may still be referenced by other modules.
skipping to change at page 139, line 7 skipping to change at page 140, line 7
(i.e., if a non-editorial change is made to any definition other than (i.e., if a non-editorial change is made to any definition other than
those specifically allowed above), then this MUST be achieved by a those specifically allowed above), then this MUST be achieved by a
new definition with a new identifier. new definition with a new identifier.
In statements which have any data definition statements as In statements which have any data definition statements as
substatements, those data definition substatements MUST NOT be substatements, those data definition substatements MUST NOT be
reordered. reordered.
11. YIN 11. YIN
A YANG module can be specified in an alternative XML-based syntax A YANG module can be translated into an alternative XML-based syntax
called YIN. This section describes symmetric mapping rules between called YIN. The translated module is called a YIN module. This
the two formats. section describes symmetric mapping rules between the two formats.
The YANG and YIN formats contain equivalent information using The YANG and YIN formats contain equivalent information using
different notations. The purpose of the YIN notation is to allow the different notations. The purpose of the YIN notation is to allow the
user to translate YANG into YIN, use the rich set of XML based tools user to translate YANG into YIN, use the rich set of XML based tools
on the YIN format to transform, or filter the model information. on the YIN format to transform, or filter the model information.
Tools like XSLT or XML validators can be utilized. After this the Tools like XSLT or XML validators can be utilized. After this the
model can be transformed back to the YANG format if needed, which model can be transformed back to the YANG format if needed, which
provides a more concise and readable format. provides a more concise and readable format.
The mapping between YANG and YIN does not modify the information The mapping between YANG and YIN does not modify the information
content of the model. Comments and whitespace are not preserved. content of the model. Comments and whitespace are not preserved.
11.1. Formal YIN Definition 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 YANG keywords belong to the
namespace whose associated URI is namespace whose associated URI is
"urn:ietf:params:xml:ns:yang:yin:1". "urn:ietf:params:xml:ns:yang:yin:1".
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
attribute or a subelement of the keyword element. Table 1 defines attribute or a subelement of the keyword element. Table 1 defines
the encoding for the set of core YANG keywords. For extensions, the the encoding for the set of YANG keywords. For extensions, the
argument encoding is specified within the "extension" statement (see argument encoding is specified within the "extension" statement (see
Section 7.17). The following rules hold for arguments of both core Section 7.17). The following rules hold for arguments:
and extension statements:
o If the argument is encoded as an attribute, this attribute has no o If the argument is encoded as an attribute, this attribute has no
namespace. namespace.
o If the argument is encoded as an element, it is placed to the same o If the argument is encoded as an element, it is placed to the same
namespace as its parent keyword element. namespace as its parent keyword element.
o If the argument is encoded as an element, it MUST be the first o If the argument is encoded as an element, it MUST be the first
child of the keyword element. child of the keyword element.
Substatements of a YANG statement are encoded as (additional) Substatements of a YANG statement are encoded as (additional)
children of the keyword element and their relative order MUST be the children of the keyword element and their relative order MUST be the
same as the order of substatements in YANG. same as the order of substatements in YANG.
Comments in YANG MAY be mapped to XML comments. Comments in YANG MAY be mapped to XML comments.
Mapping of arguments of the core YANG statements. Mapping of arguments of the YANG statements.
+------------------+---------------+-------------+ +------------------+---------------+-------------+
| keyword | argument name | yin-element | | keyword | argument name | yin-element |
+------------------+---------------+-------------+ +------------------+---------------+-------------+
| anyxml | name | false | | anyxml | name | false |
| argument | name | false | | argument | name | false |
| augment | target-node | false | | augment | target-node | false |
| base | name | false | | base | name | false |
| belongs-to | module | false | | belongs-to | module | false |
| bit | name | false | | bit | name | false |
| case | name | false | | case | name | false |
| choice | name | false | | choice | name | false |
| config | value | false | | config | value | false |
| contact | info | true | | contact | text | true |
| 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 |
skipping to change at page 141, line 13 skipping to change at page 142, line 10
| length | value | false | | length | value | false |
| list | name | false | | list | name | false |
| mandatory | value | false | | mandatory | value | false |
| max-elements | value | false | | max-elements | value | false |
| min-elements | value | false | | min-elements | value | false |
| module | name | false | | module | name | false |
| must | condition | false | | must | condition | false |
| namespace | uri | false | | namespace | uri | false |
| notification | name | false | | notification | name | false |
| ordered-by | value | false | | ordered-by | value | false |
| organization | info | true | | organization | text | true |
| output | <no argument> | n/a | | output | <no argument> | n/a |
| path | value | false | | path | value | false |
| pattern | value | false | | pattern | value | false |
| position | value | false | | position | value | false |
| prefix | value | false | | prefix | value | false |
| presence | value | false | | presence | value | false |
| range | value | false | | range | value | false |
| reference | info | false | | reference | text | true |
| refine | target-node | false | | refine | target-node | false |
| require-instance | value | false | | require-instance | value | false |
| revision | date | false | | revision | date | false |
| revision-date | date | false | | revision-date | date | false |
| rpc | name | false | | rpc | name | false |
| status | value | false | | status | value | false |
| submodule | name | false | | submodule | name | false |
| type | name | false | | type | name | false |
| typedef | name | false | | typedef | name | false |
| unique | tag | false | | unique | tag | false |
skipping to change at page 141, line 44 skipping to change at page 142, line 41
| value | value | false | | value | value | false |
| when | condition | false | | when | condition | false |
| yang-version | value | false | | yang-version | value | false |
| yin-element | value | false | | yin-element | value | false |
+------------------+---------------+-------------+ +------------------+---------------+-------------+
Table 1 Table 1
11.1.1. Usage Example 11.1.1. Usage Example
The following YANG snippet: The following YANG module:
leaf mtu { module acme-foo {
type uint32; namespace "http://acme.example.com/foo";
description "The MTU of the interface."; prefix "acfoo";
myext:c-define "MY_MTU";
import my-extensions {
prefix "myext";
}
list interface {
key "name";
leaf name {
type string;
}
leaf mtu {
type uint32;
description "The MTU of the interface.";
myext:c-define "MY_MTU";
}
}
} }
where the extension "c-define" is defined in Section 7.17.3, is where the extension "c-define" is defined in Section 7.17.3, is
translated into the following YIN snippet: translated into the following YIN:
<leaf name="mtu"> <module name="acme-foo"
<type name="uint32"/> xmlns="urn:ietf:params:xml:ns:yang:yin:1"
<description> xmlns:acfoo="http://acme.example.com/foo"
<text>The MTU of the interface.</text> xmlns:myext="http://example.com/my-extensions">
</description>
<myext:c-define name="MY_MTU"/> <namespace uri="http://acme.example.com/foo"/>
</leaf> <prefix value="acfoo"/>
<import module="my-extensions">
<prefix value="myext"/>
</import>
<list name="interface">
<key value="name"/>
<leaf name="name">
<type name="string"/>
</leaf>
<leaf name="mtu">
<type name="uint32"/>
<description>
<text>The MTU of the interface.</text>
</description>
<myext:c-define name="MY_MTU"/>
</leaf>
</list>
</module>
12. YANG ABNF Grammar 12. YANG ABNF Grammar
In YANG, almost all statements are unordered. The ABNF grammar In YANG, almost all statements are unordered. The ABNF grammar
[RFC5234] defines the canonical order. To improve module [RFC5234] defines the canonical order. To improve module
readability, it is RECOMMENDED that clauses be entered in this order. readability, it is RECOMMENDED that clauses be entered in this order.
Within the ABNF grammar, unordered statements are marked with Within the ABNF grammar, unordered statements are marked with
comments. comments.
skipping to change at page 156, line 27 skipping to change at page 158, line 27
augment-arg > augment-arg >
augment-arg = absolute-schema-nodeid augment-arg = absolute-schema-nodeid
unknown-statement = prefix ":" identifier [sep string] optsep unknown-statement = prefix ":" identifier [sep string] optsep
(";" / "{" *unknown-statement2 "}") (";" / "{" *unknown-statement2 "}")
unknown-statement2 = [prefix ":"] identifier [sep string] optsep unknown-statement2 = [prefix ":"] identifier [sep string] optsep
(";" / "{" *unknown-statement2 "}") (";" / "{" *unknown-statement2 "}")
when-stmt = when-keyword sep string stmtend when-stmt = when-keyword sep string optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")
rpc-stmt = rpc-keyword sep identifier-arg-str optsep rpc-stmt = rpc-keyword sep identifier-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
*(if-feature-stmt stmtsep) *(if-feature-stmt stmtsep)
[status-stmt stmtsep] [status-stmt stmtsep]
[description-stmt stmtsep] [description-stmt stmtsep]
[reference-stmt stmtsep] [reference-stmt stmtsep]
*((typedef-stmt / *((typedef-stmt /
skipping to change at page 162, line 28 skipping to change at page 164, line 35
prefix-arg = prefix prefix-arg = prefix
prefix = identifier prefix = identifier
identifier-arg-str = < a string which matches the rule identifier-arg-str = < a string which matches the rule
identifier-arg > identifier-arg >
identifier-arg = identifier identifier-arg = identifier
;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l'))
identifier = (ALPHA / "_") identifier = (ALPHA / "_")
*(ALPHA / DIGIT / "_" / "-" / ".") *(ALPHA / DIGIT / "_" / "-" / ".")
identifier-ref-arg-str = < a string 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 >
skipping to change at page 168, line 28 skipping to change at page 170, line 28
o for submodules, the name of the module it belongs to o for submodules, the name of the module it belongs to
o a reference to the (sub)module's documentation (the RFC number) o a reference to the (sub)module's documentation (the RFC number)
For allocation, RFC publication is required as per RFC 5226 For allocation, RFC publication is required as per RFC 5226
[RFC5226]. All registered YANG module names must comply with the [RFC5226]. All registered YANG module names must comply with the
rules for identifiers stated in Section 6.2. There are no initial rules for identifiers stated in Section 6.2. There are no initial
assignments. assignments.
The module name prefix 'ietf-' is reserved for IETF stream documents The module name prefix 'ietf-' is reserved for IETF stream documents
while the module name prefix 'irtf-' is reserved for IRTF stream [RFC4844] while the module name prefix 'irtf-' is reserved for IRTF
documents. Modules published in other RFC streams must have a stream documents. Modules published in other RFC streams must have a
similar suitable prefix. The prefix 'iana-' is reserved for modules similar suitable prefix. The prefix 'iana-' is reserved for modules
maintained by IANA. maintained by IANA.
All module and submodule names in the registry MUST be unique. All module and submodule names in the registry MUST be unique.
All XML namespaces in the registry MUST be unique. All XML namespaces in the registry MUST be unique.
This document registers two URIs for the YANG and YIN XML namespaces This document registers two URIs for the YANG and YIN XML namespaces
in the IETF XML registry [RFC3688]. Following the format in RFC in the IETF XML registry [RFC3688]. Following the format in RFC
3688, the following registration is requested. 3688, the following registration is requested.
skipping to change at page 172, line 34 skipping to change at page 174, 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.
[RFC4844] Daigle, L. and Internet Architecture Board, "The RFC
Series and RFC Editor", RFC 4844, July 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. 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, Hollander, D., Tobin, R., Thompson, H., Bray, T., and A.
"Namespaces in XML 1.0 (Second Edition)", World Wide Web Layman, "Namespaces in XML 1.0 (Third Edition)", World
Consortium Recommendation REC-xml-names-20060816, Wide Web Consortium Recommendation REC-xml-names-20091208,
August 2006, December 2009,
<http://www.w3.org/TR/2006/REC-xml-names-20060816>. <http://www.w3.org/TR/2009/REC-xml-names-20091208>.
[XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) [XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath)
Version 1.0", World Wide Web Consortium Version 1.0", World Wide Web Consortium
Recommendation REC-xpath-19991116, November 1999, Recommendation REC-xpath-19991116, November 1999,
<http://www.w3.org/TR/1999/REC-xpath-19991116>. <http://www.w3.org/TR/1999/REC-xpath-19991116>.
[XSD-TYPES] [XSD-TYPES]
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.
skipping to change at page 173, line 26 skipping to change at page 175, line 29
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.
[XPATH2.0] [XPATH2.0]
Chamberlin, D., Boag, S., Berglund, A., Robie, J., Simeon, Chamberlin, D., Boag, S., Berglund, A., Robie, J.,
J., Fernandez, M., and M. Kay, "XML Path Language (XPath) SimAfA(C)on, J., FernAfA!ndez, M., and M. Kay, "XML Path
2.0", World Wide Web Consortium Recommendation REC- Language (XPath) 2.0", World Wide Web Consortium
xpath20-20070123, January 2007, Recommendation REC-xpath20-20070123, January 2007,
<http://www.w3.org/TR/2007/REC-xpath20-20070123>. <http://www.w3.org/TR/2007/REC-xpath20-20070123>.
[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>.
Appendix A. ChangeLog Appendix A. ChangeLog
RFC Editor: remove this section upon publication as an RFC. RFC Editor: remove this section upon publication as an RFC.
A.1. Version -09 A.1. Version -10
o Added "description" and "reference" as substatements to "when".
o Make sure identifiers are XML compatible, i.e. do not start with
"xml".
o Use the terms "data node" and "schema node" instead of "node" in
the Terminology section.
o Use the character "@" as separator in recommended file names.
o Require a new "revision" statement in new versions of published
modules.
o Specified which error codes <edit-config> processing should
generate.
o Various editorial fixes and enhancements.
A.2. Version -09
o Specified that we do not specify formal rules for how the server o Specified that we do not specify formal rules for how the server
may modify configuration data stores. may modify configuration data stores.
o Added rule to allow defaults to be added to leafs in an updated o Added rule to allow defaults to be added to leafs in an updated
module. module.
o Clarified how ordered-by user lists and leaf-lists entries are o Clarified how ordered-by user lists and leaf-lists entries are
encoded in XML. encoded in XML.
o Clarified how child nodes to "case" are encoded in the XML. o Clarified how child nodes to "case" are encoded in the XML.
A.2. Version -08 A.3. Version -08
o Clarified text on leaf deafults. o Clarified text on leaf deafults.
o Added the term "top-level data node" to the terminology section. o Added the term "top-level data node" to the terminology section.
o Clarified how prefixes are mapped to namespaces in XPath o Clarified how prefixes are mapped to namespaces in XPath
expressions. expressions.
o Added "reference" as a substatement to "revision". o Added "reference" as a substatement to "revision".
o Added "choice" as a substatement to "case". o Added "choice" as a substatement to "case".
o Clarified that a leafreaf must be conditional if the leaf it o Clarified that a leafreaf must be conditional if the leaf it
refers to is conditional. refers to is conditional.
o Clarified how identityref default values are represented. o Clarified how identityref default values are represented.
o Various bug fixes, clarifications and editorial fixes. o Various bug fixes, clarifications and editorial fixes.
A.3. Version -07 A.4. Version -07
o The argument string of "augment", "refine", and "deviation" is o The argument string of "augment", "refine", and "deviation" is
described not as an XPath but as a "schema node identifier". described not as an XPath but as a "schema node identifier".
o Clarified that there must be no circular references in a leafref. o Clarified that there must be no circular references in a leafref.
A.4. Version -06 A.5. Version -06
o Various bug fixes, clarifications and editorial fixes after WGLC. o Various bug fixes, clarifications and editorial fixes after WGLC.
o Removed "require-instance" for leafref. o Removed "require-instance" for leafref.
o Allow leafrefs to refer to leaf-lists. o Allow leafrefs to refer to leaf-lists.
o Clarified the XPath context in Section 6.4.1, and for "must", o Clarified the XPath context in Section 6.4.1, and for "must",
"when", "augment", "path" and "instance-identifier". "when", "augment", "path" and "instance-identifier".
A.5. Version -05 A.6. Version -05
o Replaced the data types "float32" and "float64" with "decimal64". o Replaced the data types "float32" and "float64" with "decimal64".
o Specified that the elements in the XML encoding of configuration o Specified that the elements in the XML encoding of configuration
data can occur in any order. data can occur in any order.
o Clarified that "augment" cannot add multiple nodes with the same o Clarified that "augment" cannot add multiple nodes with the same
name. name.
o Clarified what "when" means in RPC input / output. o Clarified what "when" means in RPC input / output.
o Wrote the IANA Considerations section. o Wrote the IANA Considerations section.
o Changed requirement for minimum identifier length to 64 o Changed requirement for minimum identifier length to 64
characters. characters.
A.6. Version -04 A.7. 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 176, line 12 skipping to change at page 178, line 31
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.7. Version -03 A.8. 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.8. Version -02 A.9. 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
enforced. (yang-00172) enforced. (yang-00172)
o Added "feature" and "if-feature" statements. (yang-00750) o Added "feature" and "if-feature" statements. (yang-00750)
o Added "prefix" as a substatement to "belongs-to". (yang-00755) o Added "prefix" as a substatement to "belongs-to". (yang-00755)
skipping to change at page 177, line 5 skipping to change at page 179, line 23
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.9. Version -01 A.10. 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 178, line 5 skipping to change at page 180, line 21
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.10. Version -00 A.11. 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
 End of changes. 158 change blocks. 
451 lines changed or deleted 534 lines changed or added

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