--- 1/draft-ietf-netmod-rfc6020bis-02.txt 2015-01-05 06:14:58.828418249 -0800 +++ 2/draft-ietf-netmod-rfc6020bis-03.txt 2015-01-05 06:14:59.140425890 -0800 @@ -1,20 +1,20 @@ Network Working Group M. Bjorklund, Ed. Internet-Draft Tail-f Systems -Obsoletes: 6020 (if approved) November 14, 2014 +Obsoletes: 6020 (if approved) January 5, 2015 Intended status: Standards Track -Expires: May 18, 2015 +Expires: July 9, 2015 YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) - draft-ietf-netmod-rfc6020bis-02 + draft-ietf-netmod-rfc6020bis-03 Abstract YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. This document obsoletes RFC 6020. Status of This Memo @@ -24,25 +24,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months 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." - This Internet-Draft will expire on May 18, 2015. + This Internet-Draft will expire on July 9, 2015. Copyright Notice - Copyright (c) 2014 IETF Trust and the persons identified as the + Copyright (c) 2015 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -58,27 +58,27 @@ outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 1.1. Summary of Changes from RFC 6020 . . . . . . . . . . . . 8 2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Mandatory Nodes . . . . . . . . . . . . . . . . . . . . . 12 4. YANG Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Functional Overview . . . . . . . . . . . . . . . . . . . 12 4.2. Language Overview . . . . . . . . . . . . . . . . . . . . 14 4.2.1. Modules and Submodules . . . . . . . . . . . . . . . 14 - 4.2.2. Data Modeling Basics . . . . . . . . . . . . . . . . 14 + 4.2.2. Data Modeling Basics . . . . . . . . . . . . . . . . 15 4.2.3. State Data . . . . . . . . . . . . . . . . . . . . . 19 4.2.4. Built-In Types . . . . . . . . . . . . . . . . . . . 19 4.2.5. Derived Types (typedef) . . . . . . . . . . . . . . . 20 4.2.6. Reusable Node Groups (grouping) . . . . . . . . . . . 21 4.2.7. Choices . . . . . . . . . . . . . . . . . . . . . . . 22 4.2.8. Extending Data Models (augment) . . . . . . . . . . . 23 4.2.9. RPC Definitions . . . . . . . . . . . . . . . . . . . 24 4.2.10. Notification Definitions . . . . . . . . . . . . . . 25 5. Language Concepts . . . . . . . . . . . . . . . . . . . . . . 26 5.1. Modules and Submodules . . . . . . . . . . . . . . . . . 26 @@ -101,21 +101,21 @@ 6.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 36 6.1.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 36 6.1.3. Quoting . . . . . . . . . . . . . . . . . . . . . . . 36 6.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 37 6.2.1. Identifiers and Their Namespaces . . . . . . . . . . 38 6.3. Statements . . . . . . . . . . . . . . . . . . . . . . . 39 6.3.1. Language Extensions . . . . . . . . . . . . . . . . . 39 6.4. XPath Evaluations . . . . . . . . . . . . . . . . . . . . 39 6.4.1. XPath Context . . . . . . . . . . . . . . . . . . . . 40 6.5. Schema Node Identifier . . . . . . . . . . . . . . . . . 41 - 7. YANG Statements . . . . . . . . . . . . . . . . . . . . . . . 41 + 7. YANG Statements . . . . . . . . . . . . . . . . . . . . . . . 42 7.1. The module Statement . . . . . . . . . . . . . . . . . . 42 7.1.1. The module's Substatements . . . . . . . . . . . . . 43 7.1.2. The yang-version Statement . . . . . . . . . . . . . 44 7.1.3. The namespace Statement . . . . . . . . . . . . . . . 45 7.1.4. The prefix Statement . . . . . . . . . . . . . . . . 45 7.1.5. The import Statement . . . . . . . . . . . . . . . . 45 7.1.6. The include Statement . . . . . . . . . . . . . . . . 46 7.1.7. The organization Statement . . . . . . . . . . . . . 47 7.1.8. The contact Statement . . . . . . . . . . . . . . . . 47 7.1.9. The revision Statement . . . . . . . . . . . . . . . 47 @@ -146,213 +146,218 @@ 7.6.1. The leaf's default value . . . . . . . . . . . . . . 61 7.6.2. The leaf's Substatements . . . . . . . . . . . . . . 61 7.6.3. The leaf's type Statement . . . . . . . . . . . . . . 62 7.6.4. The leaf's default Statement . . . . . . . . . . . . 62 7.6.5. The leaf's mandatory Statement . . . . . . . . . . . 62 7.6.6. XML Mapping Rules . . . . . . . . . . . . . . . . . . 62 7.6.7. NETCONF Operations . . . . . . . . . . 63 7.6.8. Usage Example . . . . . . . . . . . . . . . . . . . . 63 7.7. The leaf-list Statement . . . . . . . . . . . . . . . . . 64 7.7.1. Ordering . . . . . . . . . . . . . . . . . . . . . . 64 - 7.7.2. The leaf-list's Substatements . . . . . . . . . . . . 65 - 7.7.3. The min-elements Statement . . . . . . . . . . . . . 65 - 7.7.4. The max-elements Statement . . . . . . . . . . . . . 66 - 7.7.5. The ordered-by Statement . . . . . . . . . . . . . . 66 - 7.7.6. XML Mapping Rules . . . . . . . . . . . . . . . . . . 67 - 7.7.7. NETCONF Operations . . . . . . . . . . 67 - 7.7.8. Usage Example . . . . . . . . . . . . . . . . . . . . 68 - 7.8. The list Statement . . . . . . . . . . . . . . . . . . . 70 - 7.8.1. The list's Substatements . . . . . . . . . . . . . . 70 - 7.8.2. The list's key Statement . . . . . . . . . . . . . . 71 - 7.8.3. The list's unique Statement . . . . . . . . . . . . . 72 - 7.8.4. The list's Child Node Statements . . . . . . . . . . 73 - 7.8.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 73 - 7.8.6. NETCONF Operations . . . . . . . . . . 74 - 7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 75 - 7.9. The choice Statement . . . . . . . . . . . . . . . . . . 78 - 7.9.1. The choice's Substatements . . . . . . . . . . . . . 78 - 7.9.2. The choice's case Statement . . . . . . . . . . . . . 79 - 7.9.3. The choice's default Statement . . . . . . . . . . . 80 - 7.9.4. The choice's mandatory Statement . . . . . . . . . . 82 - 7.9.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 82 - 7.9.6. NETCONF Operations . . . . . . . . . . 82 - 7.9.7. Usage Example . . . . . . . . . . . . . . . . . . . . 82 - 7.10. The anyxml Statement . . . . . . . . . . . . . . . . . . 83 - 7.10.1. The anyxml's Substatements . . . . . . . . . . . . . 84 - 7.10.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 84 - 7.10.3. NETCONF Operations . . . . . . . . . . 84 - 7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . 85 - 7.11. The grouping Statement . . . . . . . . . . . . . . . . . 85 - 7.11.1. The grouping's Substatements . . . . . . . . . . . . 86 - 7.11.2. Usage Example . . . . . . . . . . . . . . . . . . . 86 - 7.12. The uses Statement . . . . . . . . . . . . . . . . . . . 87 - 7.12.1. The uses's Substatements . . . . . . . . . . . . . . 87 - 7.12.2. The refine Statement . . . . . . . . . . . . . . . . 87 - 7.12.3. XML Mapping Rules . . . . . . . . . . . . . . . . . 88 - 7.12.4. Usage Example . . . . . . . . . . . . . . . . . . . 88 + 7.7.2. The leaf-list's default values . . . . . . . . . . . 65 + 7.7.3. The leaf-list's Substatements . . . . . . . . . . . . 66 + 7.7.4. The leaf-list's default Statement . . . . . . . . . . 66 + 7.7.5. The min-elements Statement . . . . . . . . . . . . . 66 + 7.7.6. The max-elements Statement . . . . . . . . . . . . . 67 + 7.7.7. The ordered-by Statement . . . . . . . . . . . . . . 67 + 7.7.8. XML Mapping Rules . . . . . . . . . . . . . . . . . . 68 + 7.7.9. NETCONF Operations . . . . . . . . . . 68 + 7.7.10. Usage Example . . . . . . . . . . . . . . . . . . . . 69 + 7.8. The list Statement . . . . . . . . . . . . . . . . . . . 71 + 7.8.1. The list's Substatements . . . . . . . . . . . . . . 71 + 7.8.2. The list's key Statement . . . . . . . . . . . . . . 72 + 7.8.3. The list's unique Statement . . . . . . . . . . . . . 73 + 7.8.4. The list's Child Node Statements . . . . . . . . . . 74 + 7.8.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 74 + 7.8.6. NETCONF Operations . . . . . . . . . . 75 + 7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 76 + 7.9. The choice Statement . . . . . . . . . . . . . . . . . . 79 + 7.9.1. The choice's Substatements . . . . . . . . . . . . . 79 + 7.9.2. The choice's case Statement . . . . . . . . . . . . . 80 + 7.9.3. The choice's default Statement . . . . . . . . . . . 81 + 7.9.4. The choice's mandatory Statement . . . . . . . . . . 83 + 7.9.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 83 + 7.9.6. NETCONF Operations . . . . . . . . . . 83 + 7.9.7. Usage Example . . . . . . . . . . . . . . . . . . . . 83 + 7.10. The anyxml Statement . . . . . . . . . . . . . . . . . . 84 + 7.10.1. The anyxml's Substatements . . . . . . . . . . . . . 85 + 7.10.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 85 + 7.10.3. NETCONF Operations . . . . . . . . . . 85 + 7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . 86 + 7.11. The grouping Statement . . . . . . . . . . . . . . . . . 86 + 7.11.1. The grouping's Substatements . . . . . . . . . . . . 87 + 7.11.2. Usage Example . . . . . . . . . . . . . . . . . . . 87 + 7.12. The uses Statement . . . . . . . . . . . . . . . . . . . 88 + 7.12.1. The uses's Substatements . . . . . . . . . . . . . . 88 + 7.12.2. The refine Statement . . . . . . . . . . . . . . . . 88 + 7.12.3. XML Mapping Rules . . . . . . . . . . . . . . . . . 89 + 7.12.4. Usage Example . . . . . . . . . . . . . . . . . . . 89 + 7.13. The rpc Statement . . . . . . . . . . . . . . . . . . . . 91 + 7.13.1. The rpc's Substatements . . . . . . . . . . . . . . 91 + 7.13.2. The input Statement . . . . . . . . . . . . . . . . 91 + 7.13.3. The output Statement . . . . . . . . . . . . . . . . 92 + 7.13.4. XML Mapping Rules . . . . . . . . . . . . . . . . . 93 + 7.13.5. Usage Example . . . . . . . . . . . . . . . . . . . 94 + 7.14. The notification Statement . . . . . . . . . . . . . . . 94 + 7.14.1. The notification's Substatements . . . . . . . . . . 95 + 7.14.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 95 + 7.14.3. Usage Example . . . . . . . . . . . . . . . . . . . 95 + 7.15. The augment Statement . . . . . . . . . . . . . . . . . . 96 + 7.15.1. The augment's Substatements . . . . . . . . . . . . 97 + 7.15.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 97 + 7.15.3. Usage Example . . . . . . . . . . . . . . . . . . . 98 + 7.16. The identity Statement . . . . . . . . . . . . . . . . . 100 + 7.16.1. The identity's Substatements . . . . . . . . . . . . 100 + 7.16.2. The base Statement . . . . . . . . . . . . . . . . . 100 + 7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . 101 + 7.17. The extension Statement . . . . . . . . . . . . . . . . . 101 + 7.17.1. The extension's Substatements . . . . . . . . . . . 102 + 7.17.2. The argument Statement . . . . . . . . . . . . . . . 102 + 7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . 103 + 7.18. Conformance-Related Statements . . . . . . . . . . . . . 103 + 7.18.1. The feature Statement . . . . . . . . . . . . . . . 104 + 7.18.2. The if-feature Statement . . . . . . . . . . . . . . 105 + 7.18.3. The deviation Statement . . . . . . . . . . . . . . 106 + 7.19. Common Statements . . . . . . . . . . . . . . . . . . . . 109 + 7.19.1. The config Statement . . . . . . . . . . . . . . . . 109 + 7.19.2. The status Statement . . . . . . . . . . . . . . . . 109 + 7.19.3. The description Statement . . . . . . . . . . . . . 110 + 7.19.4. The reference Statement . . . . . . . . . . . . . . 110 + 7.19.5. The when Statement . . . . . . . . . . . . . . . . . 111 + 8. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 111 + 8.1. Constraints on Data . . . . . . . . . . . . . . . . . . . 112 + 8.2. Hierarchy of Constraints . . . . . . . . . . . . . . . . 112 + 8.3. Constraint Enforcement Model . . . . . . . . . . . . . . 112 + 8.3.1. Payload Parsing . . . . . . . . . . . . . . . . . . . 113 + 8.3.2. NETCONF Processing . . . . . . . . . . 113 + 8.3.3. Validation . . . . . . . . . . . . . . . . . . . . . 114 + 9. Built-In Types . . . . . . . . . . . . . . . . . . . . . . . 114 + 9.1. Canonical Representation . . . . . . . . . . . . . . . . 115 + 9.2. The Integer Built-In Types . . . . . . . . . . . . . . . 115 + 9.2.1. Lexical Representation . . . . . . . . . . . . . . . 116 + 9.2.2. Canonical Form . . . . . . . . . . . . . . . . . . . 116 + 9.2.3. Restrictions . . . . . . . . . . . . . . . . . . . . 116 + 9.2.4. The range Statement . . . . . . . . . . . . . . . . . 117 + 9.2.5. Usage Example . . . . . . . . . . . . . . . . . . . . 117 + 9.3. The decimal64 Built-In Type . . . . . . . . . . . . . . . 118 + 9.3.1. Lexical Representation . . . . . . . . . . . . . . . 118 + 9.3.2. Canonical Form . . . . . . . . . . . . . . . . . . . 118 + 9.3.3. Restrictions . . . . . . . . . . . . . . . . . . . . 119 + 9.3.4. The fraction-digits Statement . . . . . . . . . . . . 119 + 9.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 119 + 9.4. The string Built-In Type . . . . . . . . . . . . . . . . 120 + 9.4.1. Lexical Representation . . . . . . . . . . . . . . . 120 + 9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 120 + 9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 120 + 9.4.4. The length Statement . . . . . . . . . . . . . . . . 120 + 9.4.5. The pattern Statement . . . . . . . . . . . . . . . . 121 + 9.4.6. The modifier Statement . . . . . . . . . . . . . . . 121 + 9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 121 + 9.5. The boolean Built-In Type . . . . . . . . . . . . . . . . 123 + 9.5.1. Lexical Representation . . . . . . . . . . . . . . . 123 + 9.5.2. Canonical Form . . . . . . . . . . . . . . . . . . . 123 + 9.5.3. Restrictions . . . . . . . . . . . . . . . . . . . . 123 + 9.6. The enumeration Built-In Type . . . . . . . . . . . . . . 123 + 9.6.1. Lexical Representation . . . . . . . . . . . . . . . 123 + 9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 123 + 9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 123 + 9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 124 + 9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 125 + 9.7. The bits Built-In Type . . . . . . . . . . . . . . . . . 126 + 9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 126 + 9.7.2. Lexical Representation . . . . . . . . . . . . . . . 126 + 9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 126 + 9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 126 + 9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 127 + 9.8. The binary Built-In Type . . . . . . . . . . . . . . . . 128 + 9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 128 + 9.8.2. Lexical Representation . . . . . . . . . . . . . . . 128 + 9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 128 + 9.9. The leafref Built-In Type . . . . . . . . . . . . . . . . 128 + 9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 129 + 9.9.2. The path Statement . . . . . . . . . . . . . . . . . 129 + 9.9.3. The require-instance Statement . . . . . . . . . . . 130 + 9.9.4. Lexical Representation . . . . . . . . . . . . . . . 130 + 9.9.5. Canonical Form . . . . . . . . . . . . . . . . . . . 130 + 9.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 130 + 9.10. The identityref Built-In Type . . . . . . . . . . . . . . 134 + 9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 134 + 9.10.2. The identityref's base Statement . . . . . . . . . . 134 + 9.10.3. Lexical Representation . . . . . . . . . . . . . . . 135 + 9.10.4. Canonical Form . . . . . . . . . . . . . . . . . . . 135 + 9.10.5. Usage Example . . . . . . . . . . . . . . . . . . . 135 - 7.13. The rpc Statement . . . . . . . . . . . . . . . . . . . . 90 - 7.13.1. The rpc's Substatements . . . . . . . . . . . . . . 90 - 7.13.2. The input Statement . . . . . . . . . . . . . . . . 90 - 7.13.3. The output Statement . . . . . . . . . . . . . . . . 91 - 7.13.4. XML Mapping Rules . . . . . . . . . . . . . . . . . 92 - 7.13.5. Usage Example . . . . . . . . . . . . . . . . . . . 92 - 7.14. The notification Statement . . . . . . . . . . . . . . . 93 - 7.14.1. The notification's Substatements . . . . . . . . . . 94 - 7.14.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 94 - 7.14.3. Usage Example . . . . . . . . . . . . . . . . . . . 94 - 7.15. The augment Statement . . . . . . . . . . . . . . . . . . 95 - 7.15.1. The augment's Substatements . . . . . . . . . . . . 96 - 7.15.2. XML Mapping Rules . . . . . . . . . . . . . . . . . 96 - 7.15.3. Usage Example . . . . . . . . . . . . . . . . . . . 96 - 7.16. The identity Statement . . . . . . . . . . . . . . . . . 98 - 7.16.1. The identity's Substatements . . . . . . . . . . . . 98 - 7.16.2. The base Statement . . . . . . . . . . . . . . . . . 99 - 7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . 99 - 7.17. The extension Statement . . . . . . . . . . . . . . . . . 100 - 7.17.1. The extension's Substatements . . . . . . . . . . . 101 - 7.17.2. The argument Statement . . . . . . . . . . . . . . . 101 - 7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . 102 - 7.18. Conformance-Related Statements . . . . . . . . . . . . . 102 - 7.18.1. The feature Statement . . . . . . . . . . . . . . . 102 - 7.18.2. The if-feature Statement . . . . . . . . . . . . . . 104 - 7.18.3. The deviation Statement . . . . . . . . . . . . . . 105 - 7.19. Common Statements . . . . . . . . . . . . . . . . . . . . 107 - 7.19.1. The config Statement . . . . . . . . . . . . . . . . 107 - 7.19.2. The status Statement . . . . . . . . . . . . . . . . 108 - 7.19.3. The description Statement . . . . . . . . . . . . . 109 - 7.19.4. The reference Statement . . . . . . . . . . . . . . 109 - 7.19.5. The when Statement . . . . . . . . . . . . . . . . . 109 - 8. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 110 - 8.1. Constraints on Data . . . . . . . . . . . . . . . . . . . 110 - 8.2. Hierarchy of Constraints . . . . . . . . . . . . . . . . 111 - 8.3. Constraint Enforcement Model . . . . . . . . . . . . . . 111 - 8.3.1. Payload Parsing . . . . . . . . . . . . . . . . . . . 111 - 8.3.2. NETCONF Processing . . . . . . . . . . 112 - 8.3.3. Validation . . . . . . . . . . . . . . . . . . . . . 113 - 9. Built-In Types . . . . . . . . . . . . . . . . . . . . . . . 113 - 9.1. Canonical Representation . . . . . . . . . . . . . . . . 113 - 9.2. The Integer Built-In Types . . . . . . . . . . . . . . . 114 - 9.2.1. Lexical 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. Lexical Representation . . . . . . . . . . . . . . . 117 - 9.3.2. Canonical Form . . . . . . . . . . . . . . . . . . . 117 - 9.3.3. Restrictions . . . . . . . . . . . . . . . . . . . . 117 - 9.3.4. The fraction-digits Statement . . . . . . . . . . . . 117 - 9.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 118 - 9.4. The string Built-In Type . . . . . . . . . . . . . . . . 118 - 9.4.1. Lexical Representation . . . . . . . . . . . . . . . 118 - 9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 119 - 9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 119 - 9.4.4. The length Statement . . . . . . . . . . . . . . . . 119 - 9.4.5. The pattern Statement . . . . . . . . . . . . . . . . 120 - 9.4.6. The modifier Statement . . . . . . . . . . . . . . . 120 - 9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 120 - 9.5. The boolean Built-In Type . . . . . . . . . . . . . . . . 121 - 9.5.1. Lexical Representation . . . . . . . . . . . . . . . 122 - 9.5.2. Canonical Form . . . . . . . . . . . . . . . . . . . 122 - 9.5.3. Restrictions . . . . . . . . . . . . . . . . . . . . 122 - 9.6. The enumeration Built-In Type . . . . . . . . . . . . . . 122 - 9.6.1. Lexical Representation . . . . . . . . . . . . . . . 122 - 9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 122 - 9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 122 - 9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 122 - 9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 123 - 9.7. The bits Built-In Type . . . . . . . . . . . . . . . . . 124 - 9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 124 - 9.7.2. Lexical Representation . . . . . . . . . . . . . . . 124 - 9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 124 - 9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 124 - 9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 125 - 9.8. The binary Built-In Type . . . . . . . . . . . . . . . . 126 - 9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 126 - 9.8.2. Lexical Representation . . . . . . . . . . . . . . . 126 - 9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 126 - 9.9. The leafref Built-In Type . . . . . . . . . . . . . . . . 126 - 9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 126 - 9.9.2. The path Statement . . . . . . . . . . . . . . . . . 127 - 9.9.3. The require-instance Statement . . . . . . . . . . . 127 - 9.9.4. Lexical Representation . . . . . . . . . . . . . . . 127 - 9.9.5. Canonical Form . . . . . . . . . . . . . . . . . . . 128 - 9.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 128 - 9.10. The identityref Built-In Type . . . . . . . . . . . . . . 131 - 9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 131 - 9.10.2. The identityref's base Statement . . . . . . . . . . 131 - 9.10.3. Lexical Representation . . . . . . . . . . . . . . . 132 - 9.10.4. Canonical Form . . . . . . . . . . . . . . . . . . . 132 - 9.10.5. Usage Example . . . . . . . . . . . . . . . . . . . 132 - 9.11. The empty Built-In Type . . . . . . . . . . . . . . . . . 134 - 9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 134 - 9.11.2. Lexical Representation . . . . . . . . . . . . . . . 134 - 9.11.3. Canonical Form . . . . . . . . . . . . . . . . . . . 134 - 9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 134 - 9.12. The union Built-In Type . . . . . . . . . . . . . . . . . 134 - 9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 135 - 9.12.2. Lexical Representation . . . . . . . . . . . . . . . 135 - 9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 135 - 9.12.4. Usage Example . . . . . . . . . . . . . . . . . . . 135 - 9.13. The instance-identifier Built-In Type . . . . . . . . . . 136 - 9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 137 - 9.13.2. Lexical Representation . . . . . . . . . . . . . . . 137 - 9.13.3. Canonical Form . . . . . . . . . . . . . . . . . . . 137 - 9.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 137 - 10. XPath Functions . . . . . . . . . . . . . . . . . . . . . . . 138 - 10.1. Functions for Node Sets . . . . . . . . . . . . . . . . 138 - 10.1.1. current() . . . . . . . . . . . . . . . . . . . . . 138 - 10.2. Functions for Strings . . . . . . . . . . . . . . . . . 138 - 10.2.1. re-match() . . . . . . . . . . . . . . . . . . . . . 138 + 9.11. The empty Built-In Type . . . . . . . . . . . . . . . . . 137 + 9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 137 + 9.11.2. Lexical Representation . . . . . . . . . . . . . . . 137 + 9.11.3. Canonical Form . . . . . . . . . . . . . . . . . . . 137 + 9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 137 + 9.12. The union Built-In Type . . . . . . . . . . . . . . . . . 137 + 9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 138 + 9.12.2. Lexical Representation . . . . . . . . . . . . . . . 138 + 9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 138 + 9.12.4. Usage Example . . . . . . . . . . . . . . . . . . . 138 + 9.13. The instance-identifier Built-In Type . . . . . . . . . . 139 + 9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 140 + 9.13.2. Lexical Representation . . . . . . . . . . . . . . . 140 + 9.13.3. Canonical Form . . . . . . . . . . . . . . . . . . . 140 + 9.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 140 + 10. XPath Functions . . . . . . . . . . . . . . . . . . . . . . . 141 + 10.1. Functions for Node Sets . . . . . . . . . . . . . . . . 141 + 10.1.1. current() . . . . . . . . . . . . . . . . . . . . . 141 + 10.2. Functions for Strings . . . . . . . . . . . . . . . . . 141 + 10.2.1. re-match() . . . . . . . . . . . . . . . . . . . . . 141 10.3. Functions for the YANG Types "leafref" and "instance- - identifier" . . . . . . . . . . . . . . . . . . . . . . 139 - 10.3.1. deref() . . . . . . . . . . . . . . . . . . . . . . 139 - 10.4. Functions for the YANG Type "identityref" . . . . . . . 140 - 10.4.1. derived-from() . . . . . . . . . . . . . . . . . . . 140 - 10.5. Functions for the YANG Type "enumeration" . . . . . . . 141 - 10.5.1. enum-value() . . . . . . . . . . . . . . . . . . . . 141 - 10.6. Functions for the YANG Type "bits" . . . . . . . . . . . 142 - 10.6.1. bit-is-set() . . . . . . . . . . . . . . . . . . . . 142 - 11. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 143 - 12. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 - 12.1. Formal YIN Definition . . . . . . . . . . . . . . . . . 145 - 12.1.1. Usage Example . . . . . . . . . . . . . . . . . . . 148 - 13. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 149 - 14. Error Responses for YANG Related Errors . . . . . . . . . . . 172 - 14.1. Error Message for Data That Violates a unique Statement 173 + identifier" . . . . . . . . . . . . . . . . . . . . . . 142 + 10.3.1. deref() . . . . . . . . . . . . . . . . . . . . . . 142 + 10.4. Functions for the YANG Type "identityref" . . . . . . . 143 + 10.4.1. derived-from() . . . . . . . . . . . . . . . . . . . 143 + 10.4.2. derived-from-or-self() . . . . . . . . . . . . . . . 143 + 10.5. Functions for the YANG Type "enumeration" . . . . . . . 144 + 10.5.1. enum-value() . . . . . . . . . . . . . . . . . . . . 144 + 10.6. Functions for the YANG Type "bits" . . . . . . . . . . . 145 + 10.6.1. bit-is-set() . . . . . . . . . . . . . . . . . . . . 145 + 11. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 146 + 12. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 + 12.1. Formal YIN Definition . . . . . . . . . . . . . . . . . 149 + 12.1.1. Usage Example . . . . . . . . . . . . . . . . . . . 151 + 13. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 152 + 14. Error Responses for YANG Related Errors . . . . . . . . . . . 176 + 14.1. Error Message for Data That Violates a unique Statement 176 14.2. Error Message for Data That Violates a max-elements - Statement . . . . . . . . . . . . . . . . . . . . . . . 173 + Statement . . . . . . . . . . . . . . . . . . . . . . . 176 14.3. Error Message for Data That Violates a min-elements - Statement . . . . . . . . . . . . . . . . . . . . . . . 173 - 14.4. Error Message for Data That Violates a must Statement . 173 + Statement . . . . . . . . . . . . . . . . . . . . . . . 176 + 14.4. Error Message for Data That Violates a must Statement . 177 14.5. Error Message for Data That Violates a require-instance - Statement . . . . . . . . . . . . . . . . . . . . . . . 174 + Statement . . . . . . . . . . . . . . . . . . . . . . . 177 14.6. Error Message for Data That Does Not Match a leafref - Type . . . . . . . . . . . . . . . . . . . . . . . . . . 174 + Type . . . . . . . . . . . . . . . . . . . . . . . . . . 177 14.7. Error Message for Data That Violates a mandatory choice - Statement . . . . . . . . . . . . . . . . . . . . . . . 174 - 14.8. Error Message for the "insert" Operation . . . . . . . . 174 - 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 175 - 15.1. Media type application/yang . . . . . . . . . . . . . . 176 - 15.2. Media type application/yin+xml . . . . . . . . . . . . . 176 - 16. Security Considerations . . . . . . . . . . . . . . . . . . . 178 - 17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 178 - 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 179 - 19. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 179 - 19.1. Version -02 . . . . . . . . . . . . . . . . . . . . . . 179 - 19.2. Version -01 . . . . . . . . . . . . . . . . . . . . . . 179 - 19.3. Version -00 . . . . . . . . . . . . . . . . . . . . . . 180 - 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 180 - 20.1. Normative References . . . . . . . . . . . . . . . . . . 180 - 20.2. Informative References . . . . . . . . . . . . . . . . . 181 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 182 + Statement . . . . . . . . . . . . . . . . . . . . . . . 177 + + 14.8. Error Message for the "insert" Operation . . . . . . . . 178 + 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 178 + 15.1. Media type application/yang . . . . . . . . . . . . . . 179 + 15.2. Media type application/yin+xml . . . . . . . . . . . . . 180 + 16. Security Considerations . . . . . . . . . . . . . . . . . . . 182 + 17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 182 + 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 183 + 19. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 183 + 19.1. Version -03 . . . . . . . . . . . . . . . . . . . . . . 183 + 19.2. Version -02 . . . . . . . . . . . . . . . . . . . . . . 183 + 19.3. Version -01 . . . . . . . . . . . . . . . . . . . . . . 183 + 19.4. Version -00 . . . . . . . . . . . . . . . . . . . . . . 184 + 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 184 + 20.1. Normative References . . . . . . . . . . . . . . . . . . 184 + 20.2. Informative References . . . . . . . . . . . . . . . . . 185 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 186 1. Introduction YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. YANG is used to model the operations and content layers of NETCONF (see the NETCONF Configuration Protocol [RFC6241], Section 1.2). This document describes the syntax and semantics of the YANG @@ -378,39 +383,51 @@ double quoted strings. This is an backwards incompatible change from YANG 1.0. A module that uses a character sequence that is now illegal must change the string to match the new rules. See Section 6.1.3 for details. o Extended the "if-feature" syntax to be a boolean expression over feature names. o Allow "if-feature" in "bit", "enum", and "identity". - o Added a set of new XPath functions in Section 10. + o Allow "if-feature" in "refine". - o Clarified the XPath context's tree in Section 6.4.1. + o Made "when" and "if-feature" illegal on list keys, unless the + parent is also conditional, and the condition matches the parent's + condition. - o Allow "must" in "input", "output", and "notification". + o Allow "choice" as a shorthand case statement (see Section 7.9). o Added a new substatement "modifier" to pattern (see Section 9.4.6). + o Allow "must" in "input", "output", and "notification". + + o Added a set of new XPath functions in Section 10. + + o Clarified the XPath context's tree in Section 6.4.1. + o Defined the string value of an identityref in XPath expressions (see Section 9.10). - o Allow "if-feature" in "refine". + o Clarified what unprefixed names means in leafrefs in typedefs (see + Section 9.9.2). - o Made "when" and "if-feature" illegal on list keys, unless the - parent is also conditional, and the condition matches the parent's - condition. + o Allow identities to be derived from multiple base identities (see + Section 7.16 and Section 9.10). - o Allow "choice" as a shorthand case statement (see Section 7.9). + o Allow enumerations to be subtyped (see Section 9.6). + + o Allow leaf-lists to have default values (see Section 7.7.2). + + o Use [RFC7405] syntax for case-sensitive strings in the grammar. 2. Keywords The keywords "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 @@ -672,22 +689,21 @@ } NETCONF XML Example: my.example.com The "leaf" statement is covered in Section 7.6. 4.2.2.2. Leaf-List Nodes - A leaf-list is a sequence of leaf nodes with exactly one value of a - particular type per leaf. + A leaf-list defines a sequence of values of a particular type. YANG Example: leaf-list domain-search { type string; description "List of domain names to search"; } NETCONF XML Example: @@ -979,24 +995,24 @@ 4.2.7. Choices YANG allows the data model to segregate incompatible nodes into distinct choices using the "choice" and "case" statements. The "choice" statement contains a set of "case" statements that define sets of schema nodes that cannot appear together. Each "case" may contain multiple nodes, but each node may appear in only one "case" under a "choice". - When a node from one case is created, all nodes from all other cases - are implicitly deleted. The device handles the enforcement of the - constraint, preventing incompatibilities from existing in the - configuration. + When a node from one case is created in the data tree, all nodes from + all other cases are implicitly deleted. The device handles the + enforcement of the constraint, preventing incompatibilities from + existing in the configuration. The choice and case nodes appear only in the schema tree, not in the data tree or NETCONF messages. The additional levels of hierarchy are not needed beyond the conceptual schema. YANG Example: container food { choice snack { case sports-arena { @@ -1784,21 +1800,24 @@ definition: o The set of namespace declarations is the set of all "import" statements' prefix and namespace pairs in the module where the XPath expression is specified, and the "prefix" statement's prefix for the "namespace" statement's URI. o Names without a namespace prefix belong to the same namespace as the identifier of the current node. Inside a grouping, that namespace is affected by where the grouping is used (see - Section 7.12). + Section 7.12). Inside a typedef, that namespace is affected by + where the typedef is referenced. If a typedef is defined and + referenced within a grouping, the namespace is affected by where + the grouping is used (see Section 7.12). o The function library is the core function library defined in [XPATH], and the functions defined in Section 10. o The set of variable bindings is empty. The mechanism for handling unprefixed names is adopted from XPath 2.0 [XPATH2.0], and helps simplify XPath expressions in YANG. No ambiguity may ever arise because YANG node identifiers are always qualified names with a non-null namespace URI. @@ -1833,22 +1852,22 @@ defined has the operation's input parameters as children. o If the XPath expression is defined in a substatement to an "output" statement in an "rpc" statement, the accessible tree is the RPC operation's output, all state data on the device, and the "running" datastore. The root node has the node representing the operation being defined and all top-level data nodes in all modules as children. The node representing the operation being defined has the operation's output parameters as children. - In the accessible tree, all leafs with default values in use exist - (See Section 7.6.1). + In the accessible tree, all leafs and leaf-lists with default values + in use exist (See Section 7.6.1 and Section 7.7.2). If a node that exists in the accessible tree has a non-presence container as a child, then the non-presence container also exists in the tree. The context node varies with the YANG XPath expression, and is specified where the YANG statement with the XPath expression is defined. 6.5. Schema Node Identifier @@ -2375,21 +2394,21 @@ The restrictions that can be applied depend on the type being restricted. The restriction statements for all built-in types are described in the subsections of Section 9. 7.4.1. The type's Substatements +------------------+---------+-------------+ | substatement | section | cardinality | +------------------+---------+-------------+ - | base | 7.16.2 | 0..1 | + | base | 7.16.2 | 0..n | | bit | 9.7.4 | 0..n | | enum | 9.6.4 | 0..n | | fraction-digits | 9.3.4 | 0..1 | | length | 9.4.4 | 0..1 | | path | 9.9.2 | 0..1 | | pattern | 9.4.5 | 0..n | | range | 9.2.4 | 0..1 | | require-instance | 9.9.3 | 0..1 | | type | 7.4 | 0..n | +------------------+---------+-------------+ @@ -2462,24 +2481,22 @@ +--------------+---------+-------------+ 7.5.3. The must Statement The "must" statement, which is optional, takes as an argument a string that contains an XPath expression (see Section 6.4). It is used to formally declare a constraint on valid data. The constraint is enforced according to the rules in Section 8. When a datastore is validated, all "must" constraints are - conceptually evaluated once for each data node in the data tree, and - for all leafs with default values in use (see Section 7.6.1). If a - data node does not exist in the data tree, and it does not have a - default value, its "must" statements are not evaluated. + conceptually evaluated once for each data node in the accessible tree + (see Section 6.4.1). All such constraints MUST evaluate to true for the data to be valid. The XPath expression is conceptually evaluated in the following context, in addition to the definition in Section 6.4.1: o The context node is the node in the accessible tree for which the "must" statement is defined. The result of the XPath expression is converted to a boolean value @@ -2821,23 +2838,20 @@ of a particular type, the "leaf-list" statement is used to define an array of a particular type. The "leaf-list" statement takes one argument, which is an identifier, followed by a block of substatements that holds detailed leaf-list information. The values in a leaf-list MUST be unique. Conceptually, the values in the data tree are always in the canonical form (see Section 9.1). - If the type referenced by the leaf-list has a default value, it has - no effect in the leaf-list. - 7.7.1. Ordering YANG supports two styles for ordering the entries within lists and leaf-lists. In many lists, the order of list entries does not impact the implementation of the list's configuration, and the device is free to sort the list entries in any reasonable order. The "description" string for the list may suggest an order to the device implementor. YANG calls this style of list "system ordered" and they are indicated with the statement "ordered-by system". @@ -2857,122 +2871,167 @@ traffic should be applied before or after the filter entry that allows all traffic from trusted interfaces. The choice of order would be crucial. YANG provides a rich set of facilities within NETCONF's operation that allows the order of list entries in user-ordered lists to be controlled. List entries may be inserted or rearranged, positioned as the first or last entry in the list, or positioned before or after another specific entry. - The "ordered-by" statement is covered in Section 7.7.5. + The "ordered-by" statement is covered in Section 7.7.7. -7.7.2. The leaf-list's Substatements +7.7.2. The leaf-list's default values + + The default values of a leaf-list are the values that the server uses + if the leaf-list does not exist in the data tree. The usage of the + default values depends on the leaf-list's closest ancestor node in + the schema tree that is not a non-presence container: + + o If no such ancestor exists in the schema tree, the default values + MUST be used. + + o Otherwise, if this ancestor is a case node, the default values + MUST be used if any node from the case exists in the data tree, or + if the case node is the choice's default case, and no nodes from + any other case exist in the data tree. + + o Otherwise, the default values MUST be used if the ancestor node + exists in the data tree. + + In these cases, the default values are said to be in use. + + When the default values are in use, the server MUST operationally + behave as if the leaf-list was present in the data tree with the + default values as its values. + + If a leaf-list has one or more "default" statement, the leaf-list's + default value are the values of the "default" statements, and if the + leaf-list is user-ordered, the default values are used in the order + of the "default" statements. Otherwise, if the leaf-list's type has + a default value, and the leaf-list does not have a "min-elements" + statement with a value greater than or equal to one, then the leaf- + list's default value is the type's default value. In all other + cases, the leaf-list does not have any default values. + +7.7.3. The leaf-list's Substatements +--------------+---------+-------------+ | substatement | section | cardinality | +--------------+---------+-------------+ | config | 7.19.1 | 0..1 | + | default | 7.7.4 | 0..n | | description | 7.19.3 | 0..1 | | if-feature | 7.18.2 | 0..n | - | max-elements | 7.7.4 | 0..1 | - | min-elements | 7.7.3 | 0..1 | + | max-elements | 7.7.6 | 0..1 | + | min-elements | 7.7.5 | 0..1 | | must | 7.5.3 | 0..n | - | ordered-by | 7.7.5 | 0..1 | + | ordered-by | 7.7.7 | 0..1 | | reference | 7.19.4 | 0..1 | | status | 7.19.2 | 0..1 | | type | 7.4 | 1 | | units | 7.3.3 | 0..1 | | when | 7.19.5 | 0..1 | +--------------+---------+-------------+ -7.7.3. The min-elements Statement +7.7.4. The leaf-list's default Statement + + The "default" statement, which is optional, takes as an argument a + string that contains a default value for the leaf-list. + + The value of the "default" statement MUST be valid according to the + type specified in the leaf-list's "type" statement. + + The "default" statement MUST NOT be present on nodes where + "min-elements" has a value greater than or equal to one. + +7.7.5. The min-elements Statement The "min-elements" statement, which is optional, takes as an argument a non-negative integer that puts a constraint on valid list entries. A valid leaf-list or list MUST have at 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 that 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. -7.7.4. The max-elements Statement +7.7.6. The max-elements Statement The "max-elements" statement, which is optional, takes as an argument a positive integer or the string "unbounded", which puts a constraint on valid list entries. A valid leaf-list or list always has at most max-elements entries. If no "max-elements" statement is present, it defaults to "unbounded". The "max-elements" constraint is enforced according to the rules in Section 8. -7.7.5. The ordered-by Statement +7.7.7. The ordered-by Statement The "ordered-by" statement defines whether the order of entries within a list are determined by the user or the system. The argument is one of the strings "system" or "user". If not present, order defaults to "system". This statement is ignored if the list represents state data, RPC output parameters, or notification content. See Section 7.7.1 for additional information. -7.7.5.1. ordered-by system +7.7.7.1. ordered-by system The entries in the list are sorted according to an unspecified order. Thus, an implementation is free to sort the entries in the most appropriate order. An implementation SHOULD use the same order for the same data, regardless of how the data were created. Using a deterministic order will make comparisons possible using simple tools like "diff". This is the default order. -7.7.5.2. ordered-by user +7.7.7.2. ordered-by user The entries in the list are sorted according to an order defined by the user. This order is controlled by using special XML attributes - in the request. See Section 7.7.7 for details. + in the request. See Section 7.7.9 for details. -7.7.6. XML Mapping Rules +7.7.8. XML Mapping Rules A leaf-list node is encoded as a series of XML elements. Each element's local name is the leaf-list's identifier, and its namespace is the module's XML namespace (see Section 7.1.3). The value of each leaf-list entry is encoded to XML according to the type, and sent as character data in the element. The XML elements representing leaf-list entries MUST appear in the order specified by the user if the leaf-list is "ordered-by user"; otherwise, the order is implementation-dependent. The XML elements representing leaf-list entries MAY be interleaved with other sibling elements, unless the leaf-list defines RPC input or output parameters. - See Section 7.7.8 for an example. + See Section 7.7.10 for an example. -7.7.7. NETCONF Operations +7.7.9. NETCONF Operations Leaf-list entries can be created and deleted, but not modified, through , by using the "operation" attribute in the leaf-list entry's XML element. 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 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 during "merge" or "replace" operations to insert a new leaf-list @@ -3001,21 +3060,21 @@ created if it does not exist. If the operation is "create", the leaf-list entry is created if it 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- 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.10. Usage Example leaf-list allow-user { type string; description "A list of user name patterns to allow"; } A corresponding XML instance example: alice bob @@ -3094,24 +3153,24 @@ | choice | 7.9 | 0..n | | config | 7.19.1 | 0..1 | | container | 7.5 | 0..n | | description | 7.19.3 | 0..1 | | grouping | 7.11 | 0..n | | if-feature | 7.18.2 | 0..n | | key | 7.8.2 | 0..1 | | leaf | 7.6 | 0..n | | leaf-list | 7.7 | 0..n | | list | 7.8 | 0..n | - | max-elements | 7.7.4 | 0..1 | - | min-elements | 7.7.3 | 0..1 | + | max-elements | 7.7.6 | 0..1 | + | min-elements | 7.7.5 | 0..1 | | must | 7.5.3 | 0..n | - | ordered-by | 7.7.5 | 0..1 | + | ordered-by | 7.7.7 | 0..1 | | reference | 7.19.4 | 0..1 | | status | 7.19.2 | 0..1 | | typedef | 7.3 | 0..n | | unique | 7.8.3 | 0..n | | uses | 7.12 | 0..n | | when | 7.19.5 | 0..1 | +--------------+---------+-------------+ 7.8.2. The list's key Statement @@ -3984,20 +4043,26 @@ value "true", the leaf MUST be present in a NETCONF RPC invocation. Otherwise, the server MUST return a "missing-element" error. 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. In these cases, the server MUST operationally behave as if the leaf was present in the NETCONF RPC invocation with the default value as its value. + If a leaf-list in the input tree has one or more default values, the + NETCONF server MUST use these values in the same cases as described + in Section 7.7.2. In these cases, the server MUST operationally + behave as if the leaf-list was present in the NETCONF RPC invocation + with the default values as its values. + If a "config" statement is present for any node in the input tree, the "config" statement is ignored. If any node has a "when" statement that 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 | @@ -4022,20 +4087,26 @@ 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 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 was present in the NETCONF RPC reply with the default value as its value. + If a leaf-list in the output tree has one or more default values, the + NETCONF client MUST use these values in the same cases as described + in Section 7.7.2. In these cases, the client MUST operationally + behave as if the leaf-list was present in the NETCONF RPC reply with + the default values as its values. + If a "config" statement is present for any node in the output tree, the "config" statement is ignored. If any node has a "when" statement that 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 | @@ -4112,20 +4183,26 @@ If a leaf in the notification tree has a "mandatory" statement with 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 client 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 was present in the NETCONF notification with the default value as its value. + If a leaf-list in the notification tree has one or more default + values, the NETCONF client MUST use these values in the same cases as + described in Section 7.7.2. In these cases, the client MUST + operationally behave as if the leaf-list was present in the NETCONF + notification with the default values as its values. + If a "config" statement is present for any node in the notification tree, the "config" statement is ignored. 7.14.1. The notification's Substatements +--------------+---------+-------------+ | substatement | section | cardinality | +--------------+---------+-------------+ | anyxml | 7.10 | 0..n | | choice | 7.9 | 0..n | @@ -4327,45 +4404,47 @@ 7.16. The identity Statement The "identity" statement is used to define a new globally unique, abstract, and untyped identity. Its only purpose is to denote its name, semantics, and existence. An identity can either be defined - from scratch or derived from a base identity. The identity's - argument is an identifier that is the name of the identity. It is - followed by a block of substatements that holds detailed identity - information. + from scratch or derived from one or more base identities. The + identity's argument is an identifier that is the name of the + identity. It is followed by a block of substatements that holds + detailed identity information. The built-in datatype "identityref" (see Section 9.10) can be used to reference identities within a data model. 7.16.1. The identity's Substatements + +--------------+---------+-------------+ | substatement | section | cardinality | +--------------+---------+-------------+ - | base | 7.16.2 | 0..1 | + | base | 7.16.2 | 0..n | | description | 7.19.3 | 0..1 | | if-feature | 7.18.2 | 0..n | | reference | 7.19.4 | 0..1 | | status | 7.19.2 | 0..1 | +--------------+---------+-------------+ 7.16.2. The base Statement The "base" statement, which is optional, takes as an argument a string that is the name of an existing identity, from which the new identity is derived. If no "base" statement is present, the identity - is defined from scratch. + is defined from scratch. If multiple "base" statements are present, + the identity is derived from all of them. If a prefix is present on the base name, it refers to an identity defined in the module that was imported with that prefix, or the local module if the prefix matches the local module's prefix. Otherwise, an identity with the matching name MUST be defined in the current module or an included submodule. Since submodules cannot include the parent module, any identities in the module that need to be exposed to submodules MUST be defined in a submodule. Submodules can then include this submodule to find the @@ -4686,33 +4766,33 @@ properties to replace are identified by substatements to the "deviate" statement. The properties to replace MUST exist in the target node. The argument "delete" deletes properties from the target node. The properties to delete are identified by substatements to the "delete" statement. The substatement's keyword MUST match a corresponding keyword in the target node, and the argument's string MUST be equal to the corresponding keyword's argument string in the target node. - +--------------+---------+-------------+ + +--------------+-------------+-------------+ | substatement | section | cardinality | - +--------------+---------+-------------+ + +--------------+-------------+-------------+ | config | 7.19.1 | 0..1 | - | default | 7.6.4 | 0..1 | + | default | 7.6.4 7.7.4 | 0..n | | mandatory | 7.6.5 | 0..1 | - | max-elements | 7.7.4 | 0..1 | - | min-elements | 7.7.3 | 0..1 | + | max-elements | 7.7.6 | 0..1 | + | min-elements | 7.7.5 | 0..1 | | must | 7.5.3 | 0..n | | type | 7.4 | 0..1 | | unique | 7.8.3 | 0..n | | units | 7.3.3 | 0..1 | - +--------------+---------+-------------+ + +--------------+-------------+-------------+ The deviate's Substatements 7.18.3.3. Usage Example In this example, the device is informing client applications that it does not support the "daytime" service in the style of RFC 867. deviation /base:system/base:daytime { deviate not-supported; @@ -5176,23 +5253,23 @@ // illegal range restriction range "11..100"; } } 9.3. The decimal64 Built-In Type 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. + 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. Lexical Representation A decimal64 value is lexically represented as an optional sign ("+" or "-"), followed by a sequence of decimal digits, optionally followed by a period ('.') as a decimal indicator and a sequence of decimal digits. If no sign is specified, "+" is assumed. 9.3.2. Canonical Form @@ -5431,37 +5508,43 @@ The lexical representation of an enumeration value is the assigned name string. 9.6.2. Canonical Form The canonical form is the assigned name string. 9.6.3. Restrictions - An enumeration cannot be restricted. + An enumeration can be restricted with the "enum" (Section 9.6.4) + statement. 9.6.4. The enum Statement The "enum" statement, which is a substatement to the "type" statement, MUST be present if the type is "enumeration". It is repeatedly used to specify each assigned name of an enumeration type. It takes as an argument a string which is the assigned name. The string MUST NOT be empty and MUST NOT have any leading or trailing whitespace characters. The use of Unicode control codes SHOULD be avoided. The statement is optionally followed by a block of substatements that holds detailed enum information. All assigned names in an enumeration MUST be unique. + When an existing enumeration type is restricted, the set of assigned + names in the new type MUST be a subset of the base type's set of + assigned names. The value of such an assigned name MUST not be + changed. + 9.6.4.1. The enum's Substatements +--------------+---------+-------------+ | substatement | section | cardinality | +--------------+---------+-------------+ | description | 7.19.3 | 0..1 | | if-feature | 7.18.2 | 0..n | | reference | 7.19.4 | 0..1 | | status | 7.19.2 | 0..1 | | value | 9.6.4.2 | 0..1 | @@ -5479,37 +5562,78 @@ If the "enum" substatement is the first one defined, the assigned value is zero (0); otherwise, the assigned value is one greater than the current highest enum value (i.e., the highest enum value, implicit or explicit, prior to the current "enum" substatement in the parent "type" statement). If the current highest value is equal to 2147483647, then an enum value MUST be specified for "enum" substatements following the one with the current highest value. + When an existing enumeration type is restricted, the "value" + statement MUST either have the same value as the in the base type or + not be present, in which case the value is the same as in the base + type. + 9.6.5. Usage Example leaf myenum { type enumeration { enum zero; enum one; enum seven { value 7; } } } The lexical representation of the leaf "myenum" with value "seven" is: seven + With the following typedef: + + typedef my-base-enumeration-type { + type enumeration { + enum white { + value 1; + } + enum yellow { + value 2; + } + enum red { + value 3; + } + } + } + + the following refinement is legal: + + type my-base-enumeration-type { + // legal enum refinement + enum yellow; + enum red { + value 3; + } + } + + and the following refinement is illegal: + + type my-base-enumeration-type { + // illegal enum refinement + enum yellow { + value 4; // illegal value change + } + enum black; // illegal addition of new name + } + 9.7. The bits Built-In Type The bits built-in type represents a bit set. That is, a bits value is a set of flags identified by small integer position numbers starting at 0. Each bit number has an assigned name. 9.7.1. Restrictions A bits type cannot be restricted. @@ -5618,23 +5742,23 @@ The leafref type is used to declare a constraint on the value space of a leaf, based on a reference to a set of leaf instances in the data tree. The "path" substatement (Section 9.9.2) selects a set of leaf instances, and the leafref value space is the set of values of these leaf instances. If the leaf with the leafref type represents configuration data, and the "require-instance" property (Section 9.9.3) is "true", the leaf it refers to MUST also represent configuration. Such a leaf puts a constraint on valid data. All such nodes MUST reference existing - leaf instances or leafs with default values in use (see - Section 7.6.1) for the data to be valid. This constraint is enforced - according to the rules in Section 8. + leaf instances or leafs with default values in use (see Section 7.6.1 + and Section 7.7.2) for the data to be valid. This constraint is + enforced according to the rules in Section 8. There MUST NOT be any circular chains of leafrefs. If the leaf that the leafref refers to is conditional based on one or more features (see Section 7.18.2), then the leaf with the leafref type MUST also be conditional based on at least the same set of features. 9.9.1. Restrictions @@ -5660,22 +5784,26 @@ list is needed. In these cases, multiple leafrefs are typically specified, and predicates are used to tie them together. The "path" expression evaluates to a node set consisting of zero, one, or more nodes. If the leaf with the leafref type represents configuration data, this node set MUST be non-empty. The "path" XPath expression is conceptually evaluated in the following 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 "path" - statement is defined. + o If the "path" statement is defined within a typedef, the context + node is the leaf or leaf-list node in the data tree that + references the typedef. + + o Otherwise, the context node is the node in the data tree for which + the "path" statement is defined. 9.9.3. The require-instance Statement The "require-instance" statement, which is a substatement to the "type" statement, MAY be present if the type is "instance-identifier" or "leafref". It takes as an argument the string "true" or "false". If this statement is not present, it defaults to "true". If "require-instance" is "true", it means that the instance being referred MUST exist for the data to be valid. This constraint is @@ -5847,49 +5975,54 @@ The identityref type is used to reference an existing identity (see Section 7.16). 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 in the module that was imported with that prefix. - Otherwise, an identity with the matching name MUST be defined in the - current module or an included submodule. + statement, MUST be present at least once 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 in the module that 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. On a particular server, the valid + Valid values for an identityref are any identities derived from all + the identityref's base identities. On a particular server, the valid values are further restricted to the set of identities defined in the modules supported by the server. 9.10.3. Lexical 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 that contains the identityref value. When an identityref is given a default value using the "default" statement, the identity name in the default value MAY have a prefix. If a prefix is present on the identity name, it refers to an identity - defined in the module that was imported with that prefix. Otherwise, - an identity with the matching name MUST be defined in the current - module or an included submodule. + defined in the module that was imported with that prefix, or the + prefix for the current module if the identity is defined in the + current module or one of its submodules. Otherwise, an identity with + the matching name MUST be defined in the current module or one of its + submodules. The string value of a node of type identityref in a "must" or "when" XPath expression is the referred identity's qualified name with the - prefix always present. + prefix present. If the referred identity is defined in an imported + module, the prefix in the string value is the prefix defined in the + corresponding "import" statement. Otherwise, the prefix in the + string value is the prefix for the current module. 9.10.4. Canonical Form Since the lexical form depends on the XML context in which the value occurs, this type does not have a canonical form. 9.10.5. Usage Example With the identity definitions in Section 7.16.3 and the following module: @@ -5978,25 +6111,24 @@ The union built-in type represents a value that corresponds to one of 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 that is the name of a member type. A member type can be of any built-in or derived type. - 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. The type - that matched will be the type of the value for the node that was - validated. + A value representing a union data type is validated consecutively + against each member type, in the order they are specified in the + "type" statement, until a match is found. The type that matched will + be the type of the value for the node that was validated. Any default value or "units" property defined in the member types is not inherited by the union type. 9.12.1. Restrictions A union cannot be restricted. However, each member type can be restricted, based on the rules defined in Section 9. 9.12.2. Lexical Representation @@ -6074,24 +6206,24 @@ values for the key nodes for list entries, a value of a leaf-list entry, or a positional index for a list without keys. For identifying list entries with keys, each predicate consists of one equality test per key, and each key MUST have a corresponding predicate. If the leaf with the instance-identifier type represents configuration data, and the "require-instance" property (Section 9.9.3) is "true", the node it refers to MUST also represent configuration. Such a leaf puts a constraint on valid data. All - such leaf nodes MUST reference existing nodes or leaf nodes with - their default value in use (see Section 7.6.1) for the data to be - valid. This constraint is enforced according to the rules in - Section 8. + such leaf nodes MUST reference existing nodes or leaf or leaf-list + nodes with their default value in use (see Section 7.6.1 and + Section 7.7.2) for the data to be valid. This constraint is enforced + according to the rules in Section 8. The "instance-identifier" XPath expression is conceptually evaluated in the following context, in addition to the definition in Section 6.4.1: o The context node is the root node in the accessible tree. 9.13.1. Restrictions An instance-identifier can be restricted with the "require-instance" @@ -6134,30 +6266,31 @@ /* instance-identifier for a leaf-list entry */ /ex:system/ex:services/ex:ssh/ex:cipher[.='blowfish-cbc'] /* instance-identifier for a list entry without keys */ /ex:stats/ex:port[3] 10. XPath Functions This document defines two generic XPath functions and four YANG type- - specific XPath functions. + specific XPath functions. The function signatures are specified with + the syntax used in [XPATH]. 10.1. Functions for Node Sets 10.1.1. current() node-set current() The function current() takes no input parameters, and returns a node - set with the initial context node. + set with the initial context node as its only member. 10.2. Functions for Strings 10.2.1. re-match() boolean re-match(string subject, string pattern) The re-match() function returns true if the "subject" string matches the regular expression "pattern"; otherwise it returns false. @@ -6226,21 +6359,34 @@ boolean derived-from(node-set nodes, string module-name, string identity-name) The derived-from() function returns true if the first node in document order in the argument "nodes" is a node of type identityref, and its value is an identity that is derived from the identity "identity-name" defined in the YANG module "module-name"; otherwise it returns false. -10.4.1.1. Usage Example +10.4.2. derived-from-or-self() + + boolean derived-from-or-self(node-set nodes, + string module-name, + string identity-name) + + The derived-from-or-self() function returns true if the first node in + document order in the argument "nodes" is a node of type identityref, + and its value is an identity that is equal to or derived from the + identity "identity-name" defined in the YANG module "module-name"; + otherwise it returns false. + +10.4.2.1. Usage Example + module example-interface { ... identity interface-type; identity ethernet { base interface-type; } identity fast-ethernet { @@ -6393,20 +6539,25 @@ o A "min-elements" statement may be removed, or changed to require fewer elements. o A "max-elements" statement may be removed, or changed to allow more elements. o A "description" statement may be added or clarified without changing the semantics of the definition. + o A "base" statement may be added to an "identity" statement. + + o A "base" statement may be removed from an "identityref" type, + provided there is at least one "base" statement left. + o New typedefs, groupings, rpcs, notifications, extensions, features, and identities may be added. o New data definition statements may be added if they do not add mandatory nodes (Section 3.1) to existing nodes or at the top level in a module or submodule, or if they are conditionally dependent on a new feature (i.e., have an "if-feature" statement that refers to a new feature). o A new "case" statement may be added. @@ -6629,21 +6780,21 @@ The MTU of the interface. 13. YANG ABNF Grammar In YANG, almost all statements are unordered. The ABNF grammar - [RFC5234] defines the canonical order. To improve module + [RFC5234] [RFC7405] defines the canonical order. To improve module readability, it is RECOMMENDED that clauses be entered in this order. Within the ABNF grammar, unordered statements are marked with comments. This grammar assumes that the scanner replaces YANG comments with a single space character. file "yang.abnf" @@ -6704,41 +6855,41 @@ leaf-stmt / leaf-list-stmt / list-stmt / choice-stmt / anyxml-stmt / uses-stmt yang-version-stmt = yang-version-keyword sep yang-version-arg-str optsep stmtend - yang-version-arg-str = < a string that matches the rule - yang-version-arg > + yang-version-arg-str = < a string that matches the rule > + < yang-version-arg > yang-version-arg = "1.1" import-stmt = import-keyword sep identifier-arg-str optsep "{" stmtsep prefix-stmt stmtsep [revision-date-stmt stmtsep] "}" include-stmt = include-keyword sep identifier-arg-str optsep (";" / "{" stmtsep [revision-date-stmt stmtsep] "}") namespace-stmt = namespace-keyword sep uri-str optsep stmtend - uri-str = < a string that matches the rule - URI in RFC 3986 > + uri-str = < a string that matches the rule > + < URI in RFC 3986 > prefix-stmt = prefix-keyword sep prefix-arg-str optsep stmtend belongs-to-stmt = belongs-to-keyword sep identifier-arg-str optsep "{" stmtsep prefix-stmt stmtsep "}" @@ -6778,31 +6929,31 @@ argument-stmt = argument-keyword sep identifier-arg-str optsep (";" / "{" stmtsep [yin-element-stmt stmtsep] "}") yin-element-stmt = yin-element-keyword sep yin-element-arg-str stmtend - yin-element-arg-str = < a string that matches the rule - yin-element-arg > + yin-element-arg-str = < a string that matches the rule > + < yin-element-arg > yin-element-arg = true-keyword / false-keyword identity-stmt = identity-keyword sep identifier-arg-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order *(if-feature-stmt stmtsep) - [base-stmt stmtsep] + *(base-stmt stmtsep) [status-stmt stmtsep] [description-stmt stmtsep] [reference-stmt stmtsep] "}") base-stmt = base-keyword sep identifier-ref-arg-str optsep stmtend feature-stmt = feature-keyword sep identifier-arg-str optsep @@ -6811,30 +6962,30 @@ ;; these stmts can appear in any order *(if-feature-stmt stmtsep) [status-stmt stmtsep] [description-stmt stmtsep] [reference-stmt stmtsep] "}") if-feature-stmt = if-feature-keyword sep if-feature-expr-str optsep stmtend - if-feature-expr-str = < a string that matches the rule - if-feature-expr > + if-feature-expr-str = < a string that matches the rule > + < if-feature-expr > - if-feature-expr = '(' if-feature-expr ')' / + if-feature-expr = "(" if-feature-expr ")" / if-feature-expr sep boolean-operator sep if-feature-expr / - 'not' sep if-feature-expr / + not-keyword sep if-feature-expr / identifier-ref-arg - boolean-operator = 'and' / 'or' + boolean-operator = and-keyword / or-keyword typedef-stmt = typedef-keyword sep identifier-arg-str optsep "{" stmtsep ;; these stmts can appear in any order type-stmt stmtsep [units-stmt stmtsep] [default-stmt stmtsep] [status-stmt stmtsep] [description-stmt stmtsep] [reference-stmt stmtsep] @@ -6869,22 +7020,22 @@ [reference-stmt stmtsep] "}") decimal64-specification = ;; these stmts can appear in any order fraction-digits-stmt [range-stmt stmtsep] fraction-digits-stmt = fraction-digits-keyword sep fraction-digits-arg-str stmtend - fraction-digits-arg-str = < a string that matches the rule - fraction-digits-arg > + fraction-digits-arg-str = < a string that matches the rule > + < fraction-digits-arg > fraction-digits-arg = ("1" ["0" / "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 @@ -6904,22 +7055,22 @@ ;; these stmts can appear in any order [modifier-stmt stmtsep] [error-message-stmt stmtsep] [error-app-tag-stmt stmtsep] [description-stmt stmtsep] [reference-stmt stmtsep] "}") modifier-stmt = modifier-keyword sep modifier-arg-str stmtend - modifier-arg-str = < a string that matches the rule - modifier-arg > + modifier-arg-str = < a string that matches the rule > + < modifier-arg > modifier-arg = invert-match-keyword default-stmt = default-keyword sep string stmtend enum-specification = 1*(enum-stmt stmtsep) enum-stmt = enum-keyword sep string optsep (";" / "{" stmtsep @@ -6934,30 +7085,30 @@ leafref-specification = ;; these stmts can appear in any order path-stmt stmtsep [require-instance-stmt stmtsep] path-stmt = path-keyword sep path-arg-str stmtend require-instance-stmt = require-instance-keyword sep require-instance-arg-str stmtend - require-instance-arg-str = < a string that matches the rule - require-instance-arg > + require-instance-arg-str = < a string that matches the rule > + < require-instance-arg > require-instance-arg = true-keyword / false-keyword instance-identifier-specification = [require-instance-stmt stmtsep] identityref-specification = - base-stmt stmtsep + 1*(base-stmt stmtsep) union-specification = 1*(type-stmt stmtsep) binary-specification = [length-stmt stmtsep] bits-specification = 1*(bit-stmt stmtsep) bit-stmt = bit-keyword sep identifier-arg-str optsep (";" / "{" stmtsep @@ -6965,95 +7116,95 @@ *(if-feature-stmt stmtsep) [position-stmt stmtsep] [status-stmt stmtsep] [description-stmt stmtsep] [reference-stmt stmtsep] "}") position-stmt = position-keyword sep position-value-arg-str stmtend - position-value-arg-str = < a string that matches the rule - position-value-arg > + position-value-arg-str = < a string that matches the rule > + < position-value-arg > position-value-arg = non-negative-integer-value status-stmt = status-keyword sep status-arg-str stmtend - status-arg-str = < a string that matches the rule - status-arg > + status-arg-str = < a string that matches the rule > + < status-arg > status-arg = current-keyword / obsolete-keyword / deprecated-keyword config-stmt = config-keyword sep config-arg-str stmtend - config-arg-str = < a string that matches the rule - config-arg > + config-arg-str = < a string that matches the rule > + < config-arg > config-arg = true-keyword / false-keyword mandatory-stmt = mandatory-keyword sep mandatory-arg-str stmtend - mandatory-arg-str = < a string that matches the rule - mandatory-arg > + mandatory-arg-str = < a string that matches the rule > + < mandatory-arg > mandatory-arg = true-keyword / false-keyword presence-stmt = presence-keyword sep string stmtend ordered-by-stmt = ordered-by-keyword sep ordered-by-arg-str stmtend - ordered-by-arg-str = < a string that matches the rule - ordered-by-arg > + ordered-by-arg-str = < a string that matches the rule > + < ordered-by-arg > ordered-by-arg = user-keyword / system-keyword must-stmt = must-keyword sep string optsep (";" / "{" stmtsep ;; these stmts can appear in any order [error-message-stmt stmtsep] [error-app-tag-stmt stmtsep] [description-stmt stmtsep] [reference-stmt stmtsep] "}") 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 that matches the rule - min-value-arg > + min-value-arg-str = < a string that matches the rule > + < min-value-arg > 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 that matches the rule - max-value-arg > + max-value-arg-str = < a string that matches the rule > + < max-value-arg > max-value-arg = unbounded-keyword / positive-integer-value value-stmt = value-keyword sep integer-value-str stmtend - integer-value-str = < a string that matches the rule - integer-value > + integer-value-str = < a string that matches the rule > + < integer-value > 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) @@ -7095,20 +7246,21 @@ "}" leaf-list-stmt = leaf-list-keyword sep identifier-arg-str optsep "{" stmtsep ;; these stmts can appear in any order [when-stmt stmtsep] *(if-feature-stmt stmtsep) type-stmt stmtsep [units-stmt stmtsep] *(must-stmt stmtsep) + *(default-stmt stmtsep) [config-stmt stmtsep] [min-elements-stmt stmtsep] [max-elements-stmt stmtsep] [ordered-by-stmt stmtsep] [status-stmt stmtsep] [description-stmt stmtsep] [reference-stmt stmtsep] "}" list-stmt = list-keyword sep identifier-arg-str optsep @@ -7126,28 +7278,29 @@ [status-stmt stmtsep] [description-stmt stmtsep] [reference-stmt stmtsep] *((typedef-stmt / grouping-stmt) stmtsep) 1*(data-def-stmt stmtsep) "}" key-stmt = key-keyword sep key-arg-str stmtend - key-arg-str = < a string that matches the rule - key-arg > + key-arg-str = < a string that matches the rule > + < key-arg > key-arg = node-identifier *(sep node-identifier) + unique-stmt = unique-keyword sep unique-arg-str stmtend - unique-arg-str = < a string that matches the rule - unique-arg > + unique-arg-str = < a string that matches the rule > + < unique-arg > unique-arg = descendant-schema-nodeid *(sep descendant-schema-nodeid) choice-stmt = choice-keyword sep identifier-arg-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order [when-stmt stmtsep] *(if-feature-stmt stmtsep) @@ -7214,57 +7368,57 @@ [presence-stmt stmtsep] [default-stmt stmtsep] [config-stmt stmtsep] [mandatory-stmt stmtsep] [min-elements-stmt stmtsep] [max-elements-stmt stmtsep] [description-stmt stmtsep] [reference-stmt stmtsep] "}" - refine-arg-str = < a string that matches the rule - refine-arg > + refine-arg-str = < a string that matches the rule > + < refine-arg > refine-arg = descendant-schema-nodeid uses-augment-stmt = augment-keyword sep uses-augment-arg-str optsep "{" stmtsep ;; these stmts can appear in any order [when-stmt stmtsep] *(if-feature-stmt stmtsep) + [status-stmt stmtsep] [description-stmt stmtsep] - [reference-stmt stmtsep] 1*((data-def-stmt stmtsep) / (case-stmt stmtsep)) "}" - uses-augment-arg-str = < a string that matches the rule - uses-augment-arg > + uses-augment-arg-str = < a string that matches the rule > + < uses-augment-arg > uses-augment-arg = descendant-schema-nodeid augment-stmt = augment-keyword sep augment-arg-str optsep "{" stmtsep ;; these stmts can appear in any order [when-stmt stmtsep] *(if-feature-stmt stmtsep) [status-stmt stmtsep] [description-stmt stmtsep] [reference-stmt stmtsep] 1*((data-def-stmt stmtsep) / (case-stmt stmtsep)) "}" - augment-arg-str = < a string that matches the rule - augment-arg > + augment-arg-str = < a string that matches the rule > + < augment-arg > augment-arg = absolute-schema-nodeid when-stmt = when-keyword sep string optsep (";" / "{" stmtsep ;; these stmts can appear in any order [description-stmt stmtsep] [reference-stmt stmtsep] "}") @@ -7321,22 +7476,22 @@ "{" stmtsep ;; these stmts can appear in any order [description-stmt stmtsep] [reference-stmt stmtsep] (deviate-not-supported-stmt / 1*(deviate-add-stmt / deviate-replace-stmt / deviate-delete-stmt)) "}" - deviation-arg-str = < a string that matches the rule - deviation-arg > + deviation-arg-str = < a string that matches the rule > + < deviation-arg > deviation-arg = absolute-schema-nodeid deviate-not-supported-stmt = deviate-keyword sep not-supported-keyword-str optsep (";" / "{" stmtsep "}") @@ -7370,31 +7525,31 @@ ;; these stmts can appear in any order [type-stmt stmtsep] [units-stmt stmtsep] [default-stmt stmtsep] [config-stmt stmtsep] [mandatory-stmt stmtsep] [min-elements-stmt stmtsep] [max-elements-stmt stmtsep] "}") - not-supported-keyword-str = < a string that matches the rule - not-supported-keyword> + not-supported-keyword-str = < a string that matches the rule > + < not-supported-keyword> - add-keyword-str = < a string that matches the rule - add-keyword> + add-keyword-str = < a string that matches the rule > + < add-keyword > - delete-keyword-str = < a string that matches the rule - delete-keyword> + delete-keyword-str = < a string that matches the rule > + < delete-keyword > - replace-keyword-str = < a string that matches the rule - replace-keyword> + replace-keyword-str = < a string that matches the rule > + < replace-keyword > ;; represents the usage of an extension statement unknown-statement = prefix ":" identifier [sep string] optsep (";" / "{" optsep *((yang-stmt / unknown-statement) optsep) "}") yang-stmt = anyxml-stmt / argument-stmt / @@ -7462,48 +7617,47 @@ units-stmt / uses-augment-stmt / uses-stmt / value-stmt / when-stmt / yang-version-stmt / yin-element-stmt ;; Ranges - range-arg-str = < a string that matches the rule - range-arg > + range-arg-str = < a string that matches the rule > + < range-arg > range-arg = range-part *(optsep "|" optsep range-part) - range-part = range-boundary [optsep ".." optsep range-boundary] range-boundary = min-keyword / max-keyword / integer-value / decimal-value ;; Lengths - length-arg-str = < a string that matches the rule - length-arg > + length-arg-str = < a string that 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-integer-value ;; Date - date-arg-str = < a string that matches the rule - date-arg > + date-arg-str = < a string that matches the rule > + < date-arg > date-arg = 4DIGIT "-" 2DIGIT "-" 2DIGIT ;; Schema Node Identifiers schema-nodeid = absolute-schema-nodeid / descendant-schema-nodeid absolute-schema-nodeid = 1*("/" node-identifier) @@ -7517,24 +7671,25 @@ 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-integer-value + ;; leafref path - path-arg-str = < a string that matches the rule - path-arg > + path-arg-str = < a string that 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] @@ -7542,135 +7697,140 @@ path-equality-expr = node-identifier *WSP "=" *WSP path-key-expr path-key-expr = current-function-invocation *WSP "/" *WSP rel-path-keyexpr rel-path-keyexpr = 1*(".." *WSP "/" *WSP) *(node-identifier *WSP "/" *WSP) node-identifier - ;;; Keywords, using abnfgen's syntax for case-sensitive strings + ;;; Keywords, using RFC 7405 syntax for case-sensitive strings ;; statement keywords - anyxml-keyword = 'anyxml' - argument-keyword = 'argument' - augment-keyword = 'augment' - base-keyword = 'base' - belongs-to-keyword = 'belongs-to' - bit-keyword = 'bit' - case-keyword = 'case' - choice-keyword = 'choice' - config-keyword = 'config' - contact-keyword = 'contact' - 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' - list-keyword = 'list' - mandatory-keyword = 'mandatory' - max-elements-keyword = 'max-elements' - min-elements-keyword = 'min-elements' - modifier-keyword = 'modifier' - module-keyword = 'module' - must-keyword = 'must' - namespace-keyword = 'namespace' - notification-keyword= 'notification' - ordered-by-keyword = 'ordered-by' - organization-keyword= 'organization' - output-keyword = 'output' - path-keyword = 'path' - pattern-keyword = 'pattern' - position-keyword = 'position' - prefix-keyword = 'prefix' - presence-keyword = 'presence' - range-keyword = 'range' - reference-keyword = 'reference' - refine-keyword = 'refine' - require-instance-keyword = 'require-instance' - revision-keyword = 'revision' - revision-date-keyword = 'revision-date' - rpc-keyword = 'rpc' - status-keyword = 'status' - submodule-keyword = 'submodule' - type-keyword = 'type' - typedef-keyword = 'typedef' - unique-keyword = 'unique' - units-keyword = 'units' - uses-keyword = 'uses' - value-keyword = 'value' - when-keyword = 'when' - yang-version-keyword= 'yang-version' - yin-element-keyword = 'yin-element' + anyxml-keyword = %s"anyxml" + argument-keyword = %s"argument" + augment-keyword = %s"augment" + base-keyword = %s"base" + belongs-to-keyword = %s"belongs-to" + bit-keyword = %s"bit" + case-keyword = %s"case" + choice-keyword = %s"choice" + config-keyword = %s"config" + contact-keyword = %s"contact" + container-keyword = %s"container" + default-keyword = %s"default" + description-keyword = %s"description" + enum-keyword = %s"enum" + error-app-tag-keyword = %s"error-app-tag" + error-message-keyword = %s"error-message" + extension-keyword = %s"extension" + deviation-keyword = %s"deviation" + deviate-keyword = %s"deviate" + feature-keyword = %s"feature" + fraction-digits-keyword = %s"fraction-digits" + grouping-keyword = %s"grouping" + identity-keyword = %s"identity" + if-feature-keyword = %s"if-feature" + import-keyword = %s"import" + include-keyword = %s"include" + input-keyword = %s"input" + key-keyword = %s"key" + leaf-keyword = %s"leaf" + leaf-list-keyword = %s"leaf-list" + length-keyword = %s"length" + list-keyword = %s"list" + mandatory-keyword = %s"mandatory" + max-elements-keyword = %s"max-elements" + min-elements-keyword = %s"min-elements" + modifier-keyword = %s"modifier" + module-keyword = %s"module" + must-keyword = %s"must" + namespace-keyword = %s"namespace" + notification-keyword= %s"notification" + ordered-by-keyword = %s"ordered-by" + organization-keyword= %s"organization" + output-keyword = %s"output" + path-keyword = %s"path" + pattern-keyword = %s"pattern" + position-keyword = %s"position" + prefix-keyword = %s"prefix" + presence-keyword = %s"presence" + range-keyword = %s"range" + reference-keyword = %s"reference" + refine-keyword = %s"refine" + require-instance-keyword = %s"require-instance" + revision-keyword = %s"revision" + revision-date-keyword = %s"revision-date" + rpc-keyword = %s"rpc" + status-keyword = %s"status" + submodule-keyword = %s"submodule" + type-keyword = %s"type" + typedef-keyword = %s"typedef" + unique-keyword = %s"unique" + units-keyword = %s"units" + uses-keyword = %s"uses" + value-keyword = %s"value" + when-keyword = %s"when" + yang-version-keyword= %s"yang-version" + yin-element-keyword = %s"yin-element" ;; other keywords - add-keyword = 'add' - current-keyword = 'current' - delete-keyword = 'delete' - deprecated-keyword = 'deprecated' - false-keyword = 'false' - invert-match-keyword = 'invert-match' - max-keyword = 'max' - min-keyword = 'min' - not-supported-keyword = 'not-supported' - obsolete-keyword = 'obsolete' - replace-keyword = 'replace' - system-keyword = 'system' - true-keyword = 'true' - unbounded-keyword = 'unbounded' - user-keyword = 'user' + + add-keyword = %s"add" + current-keyword = %s"current" + delete-keyword = %s"delete" + deprecated-keyword = %s"deprecated" + false-keyword = %s"false" + invert-match-keyword = %s"invert-match" + max-keyword = %s"max" + min-keyword = %s"min" + not-supported-keyword = %s"not-supported" + obsolete-keyword = %s"obsolete" + replace-keyword = %s"replace" + system-keyword = %s"system" + true-keyword = %s"true" + unbounded-keyword = %s"unbounded" + user-keyword = %s"user" + + and-keyword = %s"and" + or-keyword = %s"or" + not-keyword = %s"not" current-function-invocation = current-keyword *WSP "(" *WSP ")" ;;; Basic Rules - prefix-arg-str = < a string that matches the rule - prefix-arg > + prefix-arg-str = < a string that matches the rule > + < prefix-arg > prefix-arg = prefix prefix = identifier - identifier-arg-str = < a string that matches the rule - identifier-arg > + identifier-arg-str = < a string that matches the rule > + < identifier-arg > identifier-arg = identifier ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l')) identifier = (ALPHA / "_") *(ALPHA / DIGIT / "_" / "-" / ".") - identifier-ref-arg-str = < a string that matches the rule - identifier-ref-arg > + identifier-ref-arg-str = < a string that matches the rule > + < identifier-ref-arg > identifier-ref-arg = [prefix ":"] identifier - string = < an unquoted string as returned by - the scanner, that matches the rule - yang-string > + string = < an unquoted string as returned by > + < the scanner, that matches the rule > + < yang-string > yang-string = *yang-char ;; any Unicode character including tab, carriage return, and line ;; feed, but excluding the other C0 control characters, the surrogate ;; blocks, and the noncharacters. yang-char = %x9 / %xA / %xD / %x20-D7FF / ; exclude surrogate blocks %xD800-DFFF %xE000-FDCF / ; exclude noncharacters %xFDD0-FDEF %xFDF0-FFFD / ; exclude noncharacters %xFFFE-FFFF @@ -8047,33 +8205,47 @@ 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 Presuhn, David Reid, and Bert Wijnen. 19. ChangeLog RFC Editor: remove this section upon publication as an RFC. -19.1. Version -02 +19.1. Version -03 + + o Incorporated changes from WG reviews. + + o Included solution Y05-01. + + o Included solution Y10-01. + + o Included solution Y13-01. + + o Included solution Y28-02. + + o Included solution Y55-01 (parts of it was included in -01). + +19.2. Version -02 o Included solution Y02-01. o Included solution Y04-02. o Included solution Y11-01. o Included solution Y41-01. o Included solution Y56-01. -19.2. Version -01 +19.3. Version -01 o Included solution Y01-01. o Included solution Y03-01. o Included solution Y06-02. o Included solution Y07-01. o Included solution Y14-01. @@ -8083,21 +8255,21 @@ o Included solution Y23-01. o Included solution Y29-01. o Included solution Y30-01. o Included solution Y31-01. o Included solution Y35-01. -19.3. Version -00 +19.4. Version -00 o Applied all reported errata for RFC 6020. o Updated YANG version to 1.1, and made the "yang-version" statement mandatory. 20. References 20.1. Normative References @@ -8132,20 +8304,23 @@ [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. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. + [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC + 7405, December 2014. + [XML-NAMES] Hollander, D., Tobin, R., Thompson, H., Bray, T., and A. Layman, "Namespaces in XML 1.0 (Third Edition)", World Wide Web Consortium Recommendation REC-xml-names-20091208, December 2009, . [XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) Version 1.0", World Wide Web Consortium Recommendation REC-xpath-19991116, November 1999,