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