Network Modeling R. Wilton Internet-Draft Cisco Intended status: Informational 17 March 2026 Expires: 18 September 2026 YANG Next Agreement draft-wilton-netmod-yang-next-agreement-00 Abstract The purpose of this document is to discuss and hopefully find agreement on the scope and shape of the next version of YANG. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://rgwilton.github.io/yang-next-agreement/draft-wilton-netmod- yang-next-agreement.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-wilton-netmod- yang-next-agreement/. Discussion of this document takes place on the Network Modeling Working Group mailing list (mailto:netmod@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/netmod/. Subscribe at https://www.ietf.org/mailman/listinfo/netmod/. Source for this draft and an issue tracker can be found at https://github.com/rgwilton/yang-next-agreement. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 https://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 18 September 2026. Wilton Expires 18 September 2026 [Page 1] Internet-Draft YANG Next Agreement March 2026 Copyright Notice Copyright (c) 2026 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Proposed changes that should be made to YANG . . . . . . . . 7 2.1. Clarifications . . . . . . . . . . . . . . . . . . . . . 8 2.2. Minor enhancements . . . . . . . . . . . . . . . . . . . 9 2.3. Larger improvements . . . . . . . . . . . . . . . . . . . 10 3. Proposed issues to consider for the next version of YANG . . 12 4. Open issues that should not be made for the next version of YANG . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Closed issues . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Open issues proposed for closure in github . . . . . . . 18 5.2. Already closed issued in Github . . . . . . . . . . . . . 19 6. Conventions and Definitions . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 10. Normative References . . . . . . . . . . . . . . . . . . . . 22 Appendix A. List of YANG Next Github Issues . . . . . . . . . . 22 Issue 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Issue 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Issue 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Issue 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Issue 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Issue 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Issue 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Issue 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Issue 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Issue 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Issue 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Issue 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Issue 13 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Issue 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Issue 15 . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Wilton Expires 18 September 2026 [Page 2] Internet-Draft YANG Next Agreement March 2026 Issue 16 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Issue 17 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Issue 18 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Issue 19 . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Issue 20 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Issue 21 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Issue 22 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Issue 23 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Issue 24 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Issue 25 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Issue 26 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Issue 27 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Issue 28 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Issue 29 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Issue 30 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Issue 31 . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Issue 32 . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Issue 33 . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Issue 34 . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Issue 35 . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Issue 36 . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Issue 37 . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Issue 38 . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Issue 39 . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Issue 40 . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Issue 41 . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Issue 42 . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Issue 43 . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Issue 44 . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Issue 45 . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Issue 46 . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Issue 47 . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Issue 48 . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Issue 49 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Issue 50 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Issue 51 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Issue 52 . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Issue 53 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Issue 54 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Issue 55 . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Issue 56 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Issue 57 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Issue 58 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Issue 59 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Issue 60 . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Issue 61 . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Issue 62 . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Issue 63 . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Wilton Expires 18 September 2026 [Page 3] Internet-Draft YANG Next Agreement March 2026 Issue 64 . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Issue 65 . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Issue 66 . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Issue 67 . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Issue 68 . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Issue 69 . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Issue 70 . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Issue 71 . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Issue 72 . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Issue 73 . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Issue 74 . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Issue 75 . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Issue 76 . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Issue 77 . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Issue 78 . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Issue 79 . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Issue 80 . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Issue 81 . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Issue 82 . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Issue 83 . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Issue 84 . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Issue 85 . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Issue 86 . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Issue 87 . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Issue 88 . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Issue 89 . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Issue 90 . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Issue 91 . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Issue 92 . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Issue 93 . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Issue 94 . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Issue 95 . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Issue 96 . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Issue 97 . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Issue 98 . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Issue 99 . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Issue 100 . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Issue 101 . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Issue 102 . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Issue 103 . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Issue 104 . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Issue 105 . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Issue 106 . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Issue 107 . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Issue 108 . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Issue 109 . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Issue 110 . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Issue 111 . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Wilton Expires 18 September 2026 [Page 4] Internet-Draft YANG Next Agreement March 2026 Issue 112 . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Issue 113 . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Issue 114 . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Issue 115 . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Issue 116 . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Issue 117 . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Issue 118 . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Issue 119 . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Issue 120 . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Issue 121 . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Issue 122 . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Issue 123 . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Issue 124 . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Issue 125 . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Issue 126 . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Issue 127 . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Issue 128 . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Issue 129 . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Issue 130 . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Issue 131 . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Issue 132 . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Issue 133 . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Issue 134 . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Issue 135 . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Issue 136 . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Issue 137 . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Issue 138 . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Issue 139 . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Issue 140 . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Issue 141 . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Issue 142 . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Issue 143 . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Issue 144 . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Issue 145 . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Issue 146 . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Issue 147 . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Issue 148 . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Issue 149 . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Issue 150 . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Issue 151 . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Issue 152 . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Issue 153 . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Issue 154 . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Issue 155 . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Issue 156 . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 65 Wilton Expires 18 September 2026 [Page 5] Internet-Draft YANG Next Agreement March 2026 1. Introduction The YANG Next Issue Tracker (https://github.com/netmod-wg/yang-next/ issues/) lists around 125 open issues and 35 closed (some perhaps closed because they would have been non-backwards-compatible changes which were not be considered at the time that they were being evaluated). These issues are of varying size, complexity and importance. If the contents of the next version of YANG is defined solely by which issues folks would like to work on (i.e., the bazaar method) then there is a risk that we will end up with a potential large and somewhat inconsistent update to the language. It is unclear whether this would gain consensus within the IETF or widespread traction within the industry. Hence, this document proposes that attempt to reach clear consensus on what problems a revised version of YANG is intending to solve and for the issues to be categories into 4 sets: 1. issues that must be included in a next version of YANG 2. issues that should be consider for the next version of YANG (if there is sufficient interest) 3. issues that should not be considered for the next version of YANG, but could be considered for future versions. 4. issues that should not be considered further, i.e., implementing them would likely be too harmful for the language because it would make the language too big or complex or the specification would be too long. It is worth noting that a couple of separate efforts to score issues has been made, e.g., adding meta-data annotations, or closing the issues, but that in itself does not indicate what issues should be worked on. In addition, it should be noted that Appendix "Issue 152" has proposed a slightly different scoring/classification of issues (by Andy Bierman). There is no goal to publish this document as an RFC, and probably the issues could be tracked via a github dashboard. But a document like this may be a good way to ensure that the working group is aware of what changes are proposed and to ensure that there is consensus. Wilton Expires 18 September 2026 [Page 6] Internet-Draft YANG Next Agreement March 2026 2. Proposed changes that should be made to YANG The set of issues in this section are ones that the authors believe should be added to any future version of YANG. Many of these issues are clarifications, small/easy additions, or high importance issues. Summary of proposed changes: * Cleanup up the base specification: - Factor out XML encoding rules, Appendix "Issue 10" - Move NETCONF specifics out, Appendix "Issue 11" - Remove normative references to RFC 6241, Appendix "Issue 12" - Apply verified errata, Appendix "Issue 134" - Further restrict YANG Unicode to exclude "del" and C0 control characters, Appendix "Issue 125" - Is any NMDA (RFC 8342) cleanup needed (*no github tracking issue*) * Apply clarifications, 13 issues listed in Section 2.1 * Deprecations & removals : - Deprecate "import by exact revision", Appendix "Issue 75" - Remove the "anyxml" statementAppendix "Issue 105" * Fold in some keywords/functionality from extension drafts: - Incorporate structure extension, Appendix "Issue 8" - Deprecate "import by exact revision", Appendix "Issue 75" - Make NACM default-deny-all and default-deny-write built-in statements, but may need to generalize rather than being tied to NACM, Appendix "Issue 61" - YANG versioning, Appendix "Issue 45", Appendix "Issue 65", Appendix "Issue 66" * 12 minor enhancement, in Section 2.2 * 13 larger improvements, in Section 2.3 Wilton Expires 18 September 2026 [Page 7] Internet-Draft YANG Next Agreement March 2026 In total, this is about 51 of the YANG Next issues that have been raised. 2.1. Clarifications All of these issues are applying clarifications that are not intended to change the behaviour in the base specification, just make the specification clearer. For some of these issues, after review, the conclusion may be that no changes are needed. +===================================+==========================+==+ | Issue | Additional information | | +===================================+==========================+==+ | Appendix "Issue 27" Clarify YANG | | | | "status" keyword usage (e.g., | | | | hierarchical) | | | +-----------------------------------+--------------------------+--+ | Appendix "Issue 44" Clarify if | | | | multiple deviations target the | | | | same schema parts | | | +-----------------------------------+--------------------------+--+ | Appendix "Issue 88" clarify NP- | | | | containers | | | +-----------------------------------+--------------------------+--+ | Appendix "Issue 96" Clarify | This termology is | | | definitions of YANG schema tree, | confusing, we should | | | vs module schema tree | cleanup/clarify | | +-----------------------------------+--------------------------+--+ | Appendix "Issue 99" Clarify | | | | duplicate revision dates used in | | | | revision history | | | +-----------------------------------+--------------------------+--+ | Appendix "Issue 103" Clarify | | | | implicit 'case' behavior | | | +-----------------------------------+--------------------------+--+ | Appendix "Issue 104" clarify | | | | "instance-required" behavior in | | | | typedefs | | | +-----------------------------------+--------------------------+--+ | Appendix "Issue 110" Clarify | | | | canonical order in RFC 7950 | | | +-----------------------------------+--------------------------+--+ | Appendix "Issue 111" Clarify | | | | whether revision-dates must be | | | | unique or not | | | +-----------------------------------+--------------------------+--+ | Appendix "Issue 115" Clarify the | | | | meaning of properties which have | | | Wilton Expires 18 September 2026 [Page 8] Internet-Draft YANG Next Agreement March 2026 | default value | | | +-----------------------------------+--------------------------+--+ | Appendix "Issue 116" Clarify the | | | | behavior if the schema nodes in | | | | XPath expression are un-supported | | | +-----------------------------------+--------------------------+--+ | Appendix "Issue 126" Injection of | Clarify rejection, or | | | circular imports by deviation | allow circular imports | | +-----------------------------------+--------------------------+--+ | Appendix "Issue 146" | Consistent default value | | | | behavior for operations | | | | and validation | | +-----------------------------------+--------------------------+--+ Table 1: Clarifications 2.2. Minor enhancements This list of changes is for relatively minor/isolated enhancements. I.e., the changes are expected to be more isolated, or eady to add. +==============================+=============================+ | Issue | Consideration Reason | +==============================+=============================+ | Appendix "Issue 5" default | Removes unnecessary noise | | to namespace | from the language. | | urn:yang: | | +------------------------------+-----------------------------+ | Appendix "Issue 28" add | Seems like small/easy | | 'status' as a sub statement | addition | | to 'module' | | +------------------------------+-----------------------------+ | Appendix "Issue 33" Tag YANG | Seems like a small useful | | identity as an intermediate | adition | | base for classification only | | +------------------------------+-----------------------------+ | Appendix "Issue 34" Add | We should just do this, | | native support for float/ | Dec64 causes pain in specs | | double | and implementations | +------------------------------+-----------------------------+ | Appendix "Issue 59" | Should be able to introduce | | Preliminary Status | unstable data nodes to | | | mature models (e.g., | | | "status experimental") | +------------------------------+-----------------------------+ | Appendix "Issue 94" deref() | Implementations already | | function for leafref | allow this. | | statements | | Wilton Expires 18 September 2026 [Page 9] Internet-Draft YANG Next Agreement March 2026 +------------------------------+-----------------------------+ | Appendix "Issue 98" Disallow | We should just fix this | | if-feature statements where | | | enabling the feature removes | | | data nodes from the schema | | +------------------------------+-----------------------------+ | Appendix "Issue 101" allow | Simple change | | 'require-instance' to be | | | refined | | +------------------------------+-----------------------------+ | Appendix "Issue 125" Further | Same tweak to conform with | | restrict YANG Unicode to | RFC 9839 | | exclude "del" and C0 control | | | characters | | +------------------------------+-----------------------------+ | Appendix "Issue 128" Relax | Possibly dup of | | rules on usage of deprecated | Appendix "Issue 65" or | | or obsolete identifiers | Appendix "Issue 66" | +------------------------------+-----------------------------+ | Appendix "Issue 130" Add | Extra meta-data that is | | 'deprecated' statement | easy to add. | +------------------------------+-----------------------------+ | Appendix "Issue 155" Allow | Seems like a small | | hexadecimal notation for | enhancement | | enum values | | +------------------------------+-----------------------------+ Table 2: Minor Enhancements 2.3. Larger improvements This list of issues tracks more important issues that will require more work, discussion, (and probably text) to specify but are deemed to be important to help grow the language. +=========================================+=========================+ | Issue | Consideration | | | Reason | +=========================================+=========================+ | Appendix "Issue 7" Support media-type | YANG needs encoding | | specific schema that can be used to | agnostic way of | | model error-info and other mount-points | returning errors. | +-----------------------------------------+-------------------------+ | Appendix "Issue 40" Allow deviation for | E.g., to allow | | Identities | identities to be | | | marked as not- | | | supported | +-----------------------------------------+-------------------------+ Wilton Expires 18 September 2026 [Page 10] Internet-Draft YANG Next Agreement March 2026 | Appendix "Issue 49" Introduce critical | Would be allowed to | | extensions | extend YANG | | | semantics | +-----------------------------------------+-------------------------+ | Appendix "Issue 51" A general way to | Would it very | | add stmts to any part of a schema | useful, but is a | | | bigger change | +-----------------------------------------+-------------------------+ | Appendix "Issue 56" context-independent | We should have a | | encoding of instance-identifiers and | module name prefix | | identityrefs | based scheme | +-----------------------------------------+-------------------------+ | Appendix "Issue 62" Currently, list | Adding key defaults | | keys are all mandatory - allows default | would simplify some | | values for keys | model usecases | +-----------------------------------------+-------------------------+ | Appendix "Issue 70" Introduce support | Would be useful | | for critical annotations | addition | +-----------------------------------------+-------------------------+ | Appendix "Issue 76" Make submodule | Required to make | | "include" statement require a revision | module definition | | date. | sound | +-----------------------------------------+-------------------------+ | Appendix "Issue 80" enable a server | Same as issue | | express conformance to a set of | Appendix "Issue 40" | | identifiers | | +-----------------------------------------+-------------------------+ | Appendix "Issue 95" Allow an module | Adds a useful | | import to be defined as "types only" | refinement to | | | import | | | dependencies. | +-----------------------------------------+-------------------------+ | Appendix "Issue 121" Add support for | These turn up in | | hierarchical default values | modeling and should | | | be relatively easy | | | to implement. | +-----------------------------------------+-------------------------+ | Appendix "Issue 149" Error statement | Simplifies RPC/ | | for actions rpcs | protocol bindings, | | | same/similar as | | | Appendix "Issue 7" | +-----------------------------------------+-------------------------+ | Appendix "Issue 154" Add ability to | This would be | | remove nodes from a grouping in a | helpful and improve | | "uses" statement | reuse | +-----------------------------------------+-------------------------+ Table 3: Larger Improvements Wilton Expires 18 September 2026 [Page 11] Internet-Draft YANG Next Agreement March 2026 3. Proposed issues to consider for the next version of YANG This list includes items that require further evaluation. Once fully evaluated all items should end up in one of the other lists, i.e., either we plan on making the change in the next version of YANG or we don't. +=======================================+===========================+ | Issue | Consideration Reason | +=======================================+===========================+ | Appendix "Issue 2" Allow if-feature- | Too many platform files/ | | stmt inside deviation-stmt | variants. | +---------------------------------------+---------------------------+ | Appendix "Issue 4" Add a "map" | YANG list is unusal, but | | statement | too late to change? | +---------------------------------------+---------------------------+ | Appendix "Issue 13" Modify usage | Need to keep examples. | | examples to be less NETCONF focused | | +---------------------------------------+---------------------------+ | Appendix "Issue 16" Allow when in | Relatively simple | | action | addition? | +---------------------------------------+---------------------------+ | Appendix "Issue 21" Restrict regex | Would make implementation | | to a subset of XML regex | easier, could use the | | specification | IETF Regex spec? | +---------------------------------------+---------------------------+ | Appendix "Issue 26" Consider | Proposal is to deprecate | | removing support for sub modules | to simplify | | from YANG | | +---------------------------------------+---------------------------+ | Appendix "Issue 29" Clarify YANG | Was closed, but there is | | validation for data nodes 'decoded' | draft *TODO* related to | | from anydata to a tree of real nodes | this? | +---------------------------------------+---------------------------+ | Appendix "Issue 30" key-predicate- | Was closed, but perhaps | | expr should be (quoted-string / | needs to be re-evaluated | | integer-value / decimal-value) | for a YANG 2.0? | +---------------------------------------+---------------------------+ | Appendix "Issue 31" Add 'clone' | Was closed, but should | | statement | consider reuse outside | | | groupings? | +---------------------------------------+---------------------------+ | Appendix "Issue 32" Allow | Was closed, but should we | | Augmentation to Groupings | reconsider? | +---------------------------------------+---------------------------+ | Appendix "Issue 36" enable leafrefs | needs further | | to uniquely reference a nested list | investigation | +---------------------------------------+---------------------------+ Wilton Expires 18 September 2026 [Page 12] Internet-Draft YANG Next Agreement March 2026 | Appendix "Issue 39" Allow deviation | Unclear whether this is | | for description | really helpful/wise? | +---------------------------------------+---------------------------+ | Appendix "Issue 41" Allow some | Probably too big for next | | references to from config-true to | version of YANG, spec | | config-false (add capabilities) | separately | +---------------------------------------+---------------------------+ | Appendix "Issue 46" Binary encoding | Should consider, discuss | | support (lets some types have binary | with CORE folks | | persistence) | | +---------------------------------------+---------------------------+ | Appendix "Issue 57" introduce if- | Is this worth the effort? | | module | | +---------------------------------------+---------------------------+ | Appendix "Issue 58" Introduce XPath | Evaluate - Need to | | function datastore() | understand how this would | | | be used? | +---------------------------------------+---------------------------+ | Appendix "Issue 60" Allowing module | Allow some top level | | private groupings, typedefs | definitions to be private | | | to modules. | +---------------------------------------+---------------------------+ | Appendix "Issue 63" Should it be | Should consider, e.g., to | | possible to deviate "status"? | indicate obsolete nodes | | | as still being supported? | +---------------------------------------+---------------------------+ | Appendix "Issue 68" Add if-feature | Should consider | | on must stmt (removed "on import | | | stmt" part) | | +---------------------------------------+---------------------------+ | Appendix "Issue 69" Clarify | Helpful to clarify | | 'deviation' substatements to match | | | ABNF grammar | | +---------------------------------------+---------------------------+ | Appendix "Issue 72" Introduce an | Can we get unions to be | | annotation that resolves the union | consistent across | | member | encodings? | +---------------------------------------+---------------------------+ | Appendix "Issue 78" allow 'must' as | Would need to better | | a sub statement to 'grouping' | understand implications | | | first | +---------------------------------------+---------------------------+ | Appendix "Issue 81" let | Not sure how important | | 'description' be a substatement to | this is, but seems easy | | 'input' and 'output' | to add. | +---------------------------------------+---------------------------+ | Appendix "Issue 83" Clarify | Clarifications are | | canonical representation of typedefs | helpful. | Wilton Expires 18 September 2026 [Page 13] Internet-Draft YANG Next Agreement March 2026 +---------------------------------------+---------------------------+ | Appendix "Issue 84" allow | Useful if not too hard to | | notifications/actions to appear in | implement. | | invalid contexts | | +---------------------------------------+---------------------------+ | Appendix "Issue 87" enable | Was closed, but input/ | | specifying augmentation's location | output are deemed to be | | amongst siblings | ordered? | +---------------------------------------+---------------------------+ | Appendix "Issue 90" Have a mechanism | Should investigate and | | to allow enums to be extended | add if not too much | | | complexity. | +---------------------------------------+---------------------------+ | Appendix "Issue 92" enable if- | We should consider adding | | feature statements to be "refined" | this. | | into notifications and actions | | +---------------------------------------+---------------------------+ | Appendix "Issue 97" enable 'ordered- | We hit this issue when | | by' to be refined into a list or | supporting some OC models | | leaf-list | | +---------------------------------------+---------------------------+ | Appendix "Issue 100" Add errata-stmt | Need to specify/agree a | | to YANG | solution, but support | | | fixing this | +---------------------------------------+---------------------------+ | Appendix "Issue 106" Allow "input/ | Seems like a small | | output" to be defined without any | change, but what about | | child data nodes | augment ordering? | +---------------------------------------+---------------------------+ | Appendix "Issue 108" Allow when in | Probably should allow | | notification | | +---------------------------------------+---------------------------+ | Appendix "Issue 109" Change and | Should consider, but may | | compatibility rules for config=false | be too much complexity | | (state) data | | +---------------------------------------+---------------------------+ | Appendix "Issue 122" Changing an | This looks like an issue | | identity base | to consider addressing | | | (but it might be rare) | +---------------------------------------+---------------------------+ | Appendix "Issue 129" Enable | Should investigate what | | reusability without groupings | this could look like but | | | may just be too complex. | +---------------------------------------+---------------------------+ | Appendix "Issue 131" make annotation | Perhaps use critical | | a built-in YANG statement | extensions and keep out | | | of the base language | +---------------------------------------+---------------------------+ Wilton Expires 18 September 2026 [Page 14] Internet-Draft YANG Next Agreement March 2026 | Appendix "Issue 133" support for | Potentially worth | | more efficient CBOR representation | investigating | | of strings | | +---------------------------------------+---------------------------+ | Appendix "Issue 138" Add new node | Proposing a better way of | | type 'listref' | referencing lists. See | | | also Appendix "Issue 77" | +---------------------------------------+---------------------------+ | Appendix "Issue 139" Clarify adding | This might be worth | | mandatory nodes with augment + when | relaxing/clarifying | +---------------------------------------+---------------------------+ | Appendix "Issue 143" Allow | Proposal is allow more | | deviation-stmt within uses-stmt | refinement. | +---------------------------------------+---------------------------+ | Appendix "Issue 144" YANG 1.1 | Unclear if this would | | translation | even be possible ... | +---------------------------------------+---------------------------+ Table 4: Possible issue for next YANG version 4. Open issues that should not be made for the next version of YANG I think that the biggest challenges or potential long term enhancements to YANG are: * replacing XPath with a YANG specific expression language. * having a cleaner way of handling lists with multiple keys, e.g., when referenced * a generic way to augment additional statements into a YANG module. * more advanced or flexible reuse beyond groupings, including perhaps the ability to augment into a grouping. +===================================+===============================+ | Issue | Consideration Reason | +===================================+===============================+ | Appendix "Issue 14" Allow | Does this add to much | | deviations to modify "when" | complexity? | | statements | | +-----------------------------------+-------------------------------+ | Appendix "Issue 15" Incorporate/ | Not that widely used, better | | merge RFC 7952 (yang-metadata) | as a separate extension | | | rather than in core | | | document? | +-----------------------------------+-------------------------------+ | Appendix "Issue 18" add a | Done as a separate draft, | Wilton Expires 18 September 2026 [Page 15] Internet-Draft YANG Next Agreement March 2026 | templating mechanism | wait for it to mature first | +-----------------------------------+-------------------------------+ | Appendix "Issue 19" yang | Not sure whether this is | | canonical integer format | really needed. | +-----------------------------------+-------------------------------+ | Appendix "Issue 22" Restrict | Better solution may be to | | usage to a subset of XPATH | define separate YANG | | | expression langauge | +-----------------------------------+-------------------------------+ | Appendix "Issue 48" when using a | Was closed, may have too | | grouping, the designer should be | much accidental complexity? | | able to modify just about any | | | aspect of the grouping | | +-----------------------------------+-------------------------------+ | Appendix "Issue 53" Create a way | Would seem to add a lot of | | for a statement to tie-in with | complexity | | augment/deviation | | +-----------------------------------+-------------------------------+ | Appendix "Issue 54" Define a way | Nice to have. Better to do | | for extensions to declare sub- | in extension draft? | | statement validity | | +-----------------------------------+-------------------------------+ | Appendix "Issue 55" define an | Was closed, but draft | | encoding-independent "ypath:1.0" | planned. | | type | | +-----------------------------------+-------------------------------+ | Appendix "Issue 71" extension- | More investigation might be | | stmt conformance | needed, but might be too | | | much work for base YANG | | | spec. | +-----------------------------------+-------------------------------+ | Appendix "Issue 73" Initial value | Wanted by 3GPP, but | | | complexity in what it really | | | means? Does immutability | | | work come into play here. | +-----------------------------------+-------------------------------+ | Appendix "Issue 74" Support for | Adds complexity to | | unique leaf (or leaf combo) in a | implementations, is this | | list of lists | really needed? | +-----------------------------------+-------------------------------+ | Appendix "Issue 77" Add support | Not necessarily a tuple type | | for a tuple type | but would like a nicer | | | solution for multi-keyed | | | lists | +-----------------------------------+-------------------------------+ | Appendix "Issue 82" enable | Too high complexity? | | features to be supported per | | | grouping-use (not globally per- | | Wilton Expires 18 September 2026 [Page 16] Internet-Draft YANG Next Agreement March 2026 | datastore) | | +-----------------------------------+-------------------------------+ | Appendix "Issue 86" allow 'case' | Not sure it is worth the | | as a substatement to 'grouping' | complexity | +-----------------------------------+-------------------------------+ | Appendix "Issue 89" add | Not worth the additional | | 'recommended-default' statement | complexity | +-----------------------------------+-------------------------------+ | Appendix "Issue 91" Consider | Nice to have, but is it | | relaxing identity uniqueness to | worth it? | | only require uniqueness with the | | | base identity hierarchy | | +-----------------------------------+-------------------------------+ | Appendix "Issue 93" support | Some models need this, but | | 'dynamic default' | should limit the complexity. | +-----------------------------------+-------------------------------+ | Appendix "Issue 113" Treat if- | Unsure whether this is | | feature which references a non- | really needed? | | existing feature as valid YANG | | | but not enabled | | +-----------------------------------+-------------------------------+ | Appendix "Issue 119" The next | We should do something here, | | step of XPath | but it needs to be a | | | separate draft | +-----------------------------------+-------------------------------+ | Appendix "Issue 123" Allow | I don't think that we need | | identities to be active even when | to change behaviour, but | | module is not implemented | clarification might be | | | needed/helpful. | +-----------------------------------+-------------------------------+ | Appendix "Issue 127" Relax rules | Postpone to XPath | | for identityref representation | replacement | | without a prefix | | +-----------------------------------+-------------------------------+ | Appendix "Issue 147" New default- | Seems complex, does system- | | system statement to indicate that | datastore solve this anyway? | | the default value is not constant | | | (determined by the system) | | +-----------------------------------+-------------------------------+ | Appendix "Issue 148" YANG++ | This probably shouldn't be | | | YANG, but a new language | +-----------------------------------+-------------------------------+ | Appendix "Issue 150" nbc-change- | I don't think that we should | | stmt | do this now | +-----------------------------------+-------------------------------+ | Appendix "Issue 153" Allow 'when' | Not sure how this would work | | to be a child of the 'refine' | (without a container) | | statement | | Wilton Expires 18 September 2026 [Page 17] Internet-Draft YANG Next Agreement March 2026 +-----------------------------------+-------------------------------+ | Appendix "Issue 156" canonical | Need to spot data nodes that | | forms for strings (aka: the mac- | require custom handling. | | address issue) | | +-----------------------------------+-------------------------------+ Table 5: Possible issues for a future YANG version (not the next one) 5. Closed issues This set of issues are either already closed or the author believes that they should be closed and should not be consider further for any future version of YANG. Issues may be put in this section for any of these reasons: * the issue is already marked as closed in github, not some closed issues are present on the previous lists because the authors believe that circumstances have changed (i.e., a YANG 2.0 version might be an option) and the issues should be reconsidered. * the issue is a duplicate * the issue is due to a misunderstanding of the YANG language or specification * the consensus is that adding/introducing this issue would be harmful to the YANG language, perhaps taking it too far from its goals, or introducing too much complexity. * this issue relates to the protocols not the language and hence the issue should be moved to a network protocol issue tracker. 5.1. Open issues proposed for closure in github This list of issues are not currently marked as being closed in github, but the author is proposing that we close them, in that we _currently_ do not consider them for implementation in any YANG version. +==================================+================================+ | Issues Proposed for Closure | Closure Justification | +==================================+================================+ | Appendix "Issue 6" Provide a | Perceived benefit is | | correct ABNF for Yang strings | not worth the effort | +----------------------------------+--------------------------------+ | Appendix "Issue 17" replace | I'm not convinced this | | 'encoding' with 'representation' | is really necessary | Wilton Expires 18 September 2026 [Page 18] Internet-Draft YANG Next Agreement March 2026 +----------------------------------+--------------------------------+ | Appendix "Issue 102" ascii vs. | Seems too low priority, | | unicode strings | should close (also need | | | to fix link) | +----------------------------------+--------------------------------+ | Appendix "Issue 107" Add | Dup of Appendix "Issue | | deviate(not-supported) support | 40", should close | | for identities | | +----------------------------------+--------------------------------+ | Appendix "Issue 112" Support for | Seems too complex, | | conditional default values | should close | +----------------------------------+--------------------------------+ | Appendix "Issue 117" Add dynamic | Solution looks very | | feature to YANG | complex. | +----------------------------------+--------------------------------+ | Appendix "Issue 124" Add ability | Should close, dup of | | to deviate or change status of | Appendix "Issue 40" | | an identity | | +----------------------------------+--------------------------------+ | Appendix "Issue 135" Make YANG | Dup of Appendix "Issue | | Semver real statements instead | 45" | | of extensions | | +----------------------------------+--------------------------------+ | Appendix "Issue 136" Revise | Should be covered by | | Module Update Rules | Appendix "Issue 45" | +----------------------------------+--------------------------------+ | Appendix "Issue 140" grouping | Propose closing, should | | usage requirements | be in rfc8407bis | +----------------------------------+--------------------------------+ | Appendix "Issue 141" Add | Proposing closing, this | | automatic list key generation | is a protocol not YANG | | (autokey) | issue | +----------------------------------+--------------------------------+ | Appendix "Issue 145" Let a | Propose closing, not | | presence container have a | implementable | | default presence? | | +----------------------------------+--------------------------------+ | Appendix "Issue 151" YANG | Too complicated, | | profiles and views | packages may help | +----------------------------------+--------------------------------+ Table 6: Currently open issues proposed for closure 5.2. Already closed issued in Github This follow list of issues are those already marked as being closed in the YANG Next Github tracker. Wilton Expires 18 September 2026 [Page 19] Internet-Draft YANG Next Agreement March 2026 +========================================+=========================+ | Already Closed Issues | Closure Justification | +========================================+=========================+ | Appendix "Issue 1" Only one idea per | Not a YANG issue (used | | issue please! | for tracking only) | +----------------------------------------+-------------------------+ | Appendix "Issue 3" Allow prefix | Undesirable change | | statement to be optional for modules | | | that don't need it | | +----------------------------------------+-------------------------+ | Appendix "Issue 9" Add an inactive | Protocol extension not | | metadata annotation | a language feature | +----------------------------------------+-------------------------+ | Appendix "Issue 20" add explicit | Duplicate of | | module version-stmt | Appendix "Issue 45" | +----------------------------------------+-------------------------+ | Appendix "Issue 23" add 'conformance- | Probably better done | | type' leaf to 'import' statement | separately (e.g., | | | packages) | +----------------------------------------+-------------------------+ | Appendix "Issue 24" add a 'backwards- | Duplicate of | | compatibility' leaf to 'revision' | Appendix "Issue 45" | | statement | | +----------------------------------------+-------------------------+ | Appendix "Issue 25" make yang more | Too complicated - | | object-oriented | better discuss as part | | | of Appendix "Issue 148" | +----------------------------------------+-------------------------+ | Appendix "Issue 35" Simplify 'when' | Closed, *TODO* possibly | | statement processing | should be moved to be | | | part of protocol spec? | +----------------------------------------+-------------------------+ | Appendix "Issue 37" YANG ANBF could be | Not worth changing now | | defined in a simpler way | | +----------------------------------------+-------------------------+ | Appendix "Issue 38" Allow action to be | Undesirable behaviour | | invoked in the context of | | | configuration datastore | | +----------------------------------------+-------------------------+ | Appendix "Issue 42" make schema-mount | Critial extension might | | extension into a built-in statement | be a better choice | +----------------------------------------+-------------------------+ | Appendix "Issue 43" Support for | Too complex, other | | multiple key statements in a list | alternatives exist | +----------------------------------------+-------------------------+ | Appendix "Issue 47" support external | Could be done in YANG | | module requirements | library, packages. | +----------------------------------------+-------------------------+ Wilton Expires 18 September 2026 [Page 20] Internet-Draft YANG Next Agreement March 2026 | Appendix "Issue 50" YANG Packages | Separate draft, also | | (multi-module conformance/guidance) | not a language issue. | | | But perhaps want to | | | discuss conformance. | +----------------------------------------+-------------------------+ | Appendix "Issue 52" add a statement | Better done witih | | for modeling checkbox dialogs | extensions/overlay | +----------------------------------------+-------------------------+ | Appendix "Issue 64" Clarify if double | Deemed unnecessary | | quotes are needed around identifiers | | +----------------------------------------+-------------------------+ | Appendix "Issue 67" clarify "require- | Deemed not to be an | | instance" property for leafrefs | issue | +----------------------------------------+-------------------------+ | Appendix "Issue 79" add 'unique' as a | Not needed | | substatement to 'leaf-list' | | +----------------------------------------+-------------------------+ | Appendix "Issue 85" add "uses" as a | ALready supported in | | sub-statement to "augment" | YANG 1.1 | +----------------------------------------+-------------------------+ | Appendix "Issue 114" Don't treat non- | Too hard to implement | | exist import module as a error if | | | there is no any effective reference to | | | this import module in current module | | +----------------------------------------+-------------------------+ | Appendix "Issue 118" Co-existence | Can't change existing | | between YANG1.0 and YANG1.1 | specifications. | +----------------------------------------+-------------------------+ | Appendix "Issue 120" allow more | Closed as a duplicate | | restriction on Identity-ref | of other issues | +----------------------------------------+-------------------------+ | Appendix "Issue 132" Allow config=true | Closed as dup | | list without a key-stmt | | +----------------------------------------+-------------------------+ | Appendix "Issue 137" Add validation- | Closed, seems too | | rules-stmt to identify YANG validation | complex | | scope | | +----------------------------------------+-------------------------+ | Appendix "Issue 142" Allow if-feature | Duplicate of | | on deviations | Appendix "Issue 2" | +----------------------------------------+-------------------------+ Table 7: Already closed issues Wilton Expires 18 September 2026 [Page 21] Internet-Draft YANG Next Agreement March 2026 6. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 7. Security Considerations N/A. This document is only intended to help the WG reach consensus on the future direction of YANG and contains no protocol work. 8. IANA Considerations This document has no IANA actions. 9. Acknowledgments TODO acknowledge. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Appendix A. List of YANG Next Github Issues This appendix summarizes issues from the YANG-next issue tracker. The summarization was created by LLM so it may not be entirely accurate. Issue 1 (https://github.com/netmod-wg/yang-next/issues/1) *Only one idea per issue please!* Requested that issues be split so each issue covers one idea to ease prioritization and tracking. Closed as a process note rather than a YANG language issue. * *Github Labels*: Not a YANG Issue Wilton Expires 18 September 2026 [Page 22] Internet-Draft YANG Next Agreement March 2026 * *Status*: closed Issue 2 (https://github.com/netmod-wg/yang-next/issues/2) *Allow if-feature-stmt inside deviation-stmt* Customers have complained that each platform/revision needs its own deviation file. They would like to define features matching platforms and have 1 deviations file per product family. * *Github Labels*: complexity-med, backcompat-high, importance-med * *Status*: open Issue 3 (https://github.com/netmod-wg/yang-next/issues/3) *Allow prefix statement to be optional for modules that don't need it* Proposed making the prefix statement optional when a module does not reference its own prefix. Objections noted parser ambiguity and the benefit of consistent prefixes across imports. Closed. * *Github Labels*: Undesirable outcome * *Status*: closed Issue 4 (https://github.com/netmod-wg/yang-next/issues/4) *Add a "map" statement* From 9.2. YANG lists as maps YANG has two list constructs, the 'leaf-list' which is similar to a list of scalars (arrays) in other programming languages, and the 'list' which allows a keyed list of complex structures, where the key is also part of the data values. * *Github Labels*: complexity-high, backcompat-high, importance-med * *Status*: open Issue 5 (https://github.com/netmod-wg/yang-next/issues/5) *default to namespace urn:yang: ?* Wilton Expires 18 September 2026 [Page 23] Internet-Draft YANG Next Agreement March 2026 On 4/20/16, 7:47 AM, "netmod on behalf of Juergen Schoenwaelder" wrote: > On Tue, Apr 19, 2016 at 09:37:03PM +0200, Martin Bjorklund wrote: > > But I like urn:yang: even more - and if we had this, we > wouldn't have to use the "namespace" statement. * *Github Labels*: complexity-med, backcompat-high, importance-low * *Status*: open Issue 6 (https://github.com/netmod-wg/yang-next/issues/6) *Provide a correct ABNF for Yang strings* (This is derived from a mailing list message, The issue that concerns me is that the ABNF doesn't specify what is allowed as a string. I'm used to programming language definitions, where the grammar is specified quite rigidly, to the point that the ABNF can be input to a parser generator. * *Github Labels*: complexity-low, backcompat-high, importance-low * *Status*: open Issue 7 (https://github.com/netmod-wg/yang-next/issues/7) *Support media-type specific schema that can be used to model error- info and other mount-points* The element included in NETCONF and RESTCONF is very useful but there is no way to specify YANG schema to match expected data-model specific content. The ietf-restconf module defines the restconf-media-type extension that uses groupings to define this sort of data so they do not appear to be data nodes. * *Github Labels*: complexity-med, backcompat-high, importance-high * *Status*: open Issue 8 (https://github.com/netmod-wg/yang-next/issues/8) *Incorporate/merge RESTCONF's artifact extension (e.g. rc:yang-data)* The head of the on-list thread is here: But for some reason it doesn't thread-in some responses: Note: the last response does seem to have threading working again, so be sure to check out other responses from others. Wilton Expires 18 September 2026 [Page 24] Internet-Draft YANG Next Agreement March 2026 * *Github Labels*: complexity-low, backcompat-high, importance-low * *Status*: open Issue 9 (https://github.com/netmod-wg/yang-next/issues/9) *Add an inactive metadata annotation* The conditional-enablement draft seems to have support, but no one wants to rev NC/RC for it, so adding it into a rev of YANG might be the best option... * *Github Labels*: importance-med, backcompat-unknown, complexity- unknown, Workaround is better * *Status*: open Issue 10 (https://github.com/netmod-wg/yang-next/issues/10) *Move normative XML encoding rules into its own RFC* The YANG RFC is littered with XML encoding rules (see table of contents). These should be factored out into another document like RFC 7951. * *Github Labels*: complexity-med, backcompat-high, importance-med * *Status*: open Issue 11 (https://github.com/netmod-wg/yang-next/issues/11) *Move NETCONF-specific sections to NETCONF WG documents* The YANG RFC is contains sections entitled "NETCONF XML Encoding Rules" that don't belong in the YANG spec. These should be moved to some future version of 6241, or another draft maintained by the NETCONF WG. * *Github Labels*: complexity-med, backcompat-high, importance-med * *Status*: open Issue 12 (https://github.com/netmod-wg/yang-next/issues/12) *Remove normative references to RFC 6241* Wilton Expires 18 September 2026 [Page 25] Internet-Draft YANG Next Agreement March 2026 The YANG specification should not have any normative references to RFC 6241. Other than the references from the sections to be removed via issue #11, the only other substantive references are in the Terminology section, which references the following form RFC 6241: o configuration data o configuration datastore o datastore o state data These should probably be moved to the datastore RFC... * *Github Labels*: complexity-low, backcompat-high, importance-med * *Status*: open Issue 13 (https://github.com/netmod-wg/yang-next/issues/13) *Modify usage examples to be less NETCONF focused* The Usage Example sections throughout the spec illustrate NETCONF usage. Either these examples should be updated to be equal parts NETCONF and RESTCONF, or they should be removed entirely. * *Github Labels*: complexity-low, backcompat-high, importance-med * *Status*: open Issue 14 (https://github.com/netmod-wg/yang-next/issues/14) *Allow deviations to modify "when" statements* Should be self-explanatory; allow deviations to add, remove or replace when statements like they can with must statements. * *Github Labels*: complexity-med, backcompat-high, importance-med * *Status*: open Issue 15 (https://github.com/netmod-wg/yang-next/issues/15) *Incorporate/merge RFC 7952 (yang-metadata)* RFC 7952 says: Due to the rules for YANG extensions (see Section 6.3.1 in ), annotation definitions posit relatively weak conformance requirements. The alternative of introducing a new built-in YANG statement for defining annotations was considered, but it was seen as a major change to the language that is inappropriate for YANG 1.1, which was chartered as a maintenance revision. * *Github Labels*: complexity-low, backcompat-high, importance-low * *Status*: open Wilton Expires 18 September 2026 [Page 26] Internet-Draft YANG Next Agreement March 2026 Issue 16 (https://github.com/netmod-wg/yang-next/issues/16) *Allow when in action* It would be good to be able to define an action when the value of a certain leaf is set to a (set of) specific value(s). For example: in case we want to reset specific HW components one might think to define a reset action, however certain components (identified by a HW class) might not be supporting a reset. * *Github Labels*: complexity-low, backcompat-high, importance-med * *Status*: open Issue 17 (https://github.com/netmod-wg/yang-next/issues/17) *replace 'encoding' with 'representation'?* Discussion starts here: Lada says: > Yes, "representation" should be one of the terms newly defined in 7950bis, and it can also be mentioned that "encoding" was used informally in the past. * *Github Labels*: complexity-low, backcompat-high, importance-low * *Status*: open Issue 18 (https://github.com/netmod-wg/yang-next/issues/18) *add a templating mechanism?* Templates are not a datastore-specific concept, they can equally well be used in artifacts (static documents)... * *Github Labels*: complexity-high, backcompat-high, importance-med * *Status*: open Issue 19 (https://github.com/netmod-wg/yang-next/issues/19) *yang canonical integer format* The canonical format for integer types is the decimal representation. We do not seem to have a mechanism (other than a description statement) to declare that the canonical representation is lets say hexadecimal. * *Github Labels*: backcompat-high, importance-low, complexity- unknown Wilton Expires 18 September 2026 [Page 27] Internet-Draft YANG Next Agreement March 2026 * *Status*: open Issue 20 (https://github.com/netmod-wg/yang-next/issues/20) *add explicit module version-stmt* Proposed a module-version statement to avoid parsing revision history for the current version. Considered redundant and addressed by versioning work (issue #45), so closed as duplicate. * *Github Labels*: Duplicate * *Status*: closed Issue 21 (https://github.com/netmod-wg/yang-next/issues/21) *Restrict regex to a subset of XML regex specification* The choice in YANG to use XML regex has effectively meant that there is only a single library implementation of regex parsing. In most cases, the pattern statements only use the basic subset of the XML regex, and normally these pattern statements would validate against most standard regex engines with only a minimal amount of changes (it might be necessary to add anchors at the start and end of the line. * *Github Labels*: complexity-high, backcompat-low, importance-low * *Status*: open Issue 22 (https://github.com/netmod-wg/yang-next/issues/22) *Restrict usage to a subset of XPATH* XPATH expressions can be complicated, hard to read, and it is easy to express stuff that (i) implementations don't generally support, or (ii) are not what the author intended. I think that it would be useful to define a subset of XPATH that is allowed/valid, or possibly even consider defining a simpler YANG specific DSL. * *Github Labels*: complexity-med, backcompat-med, importance-low * *Status*: open Issue 23 (https://github.com/netmod-wg/yang-next/issues/23) *add 'conformance-type' leaf to 'import' statement* Wilton Expires 18 September 2026 [Page 28] Internet-Draft YANG Next Agreement March 2026 Suggested indicating why a module is imported to aid implementers and catalogs. Comments questioned the problem being solved since tools can already infer usage. Closed. * *Github Labels*: importance-low, backcompat-unknown, complexity- unknown * *Status*: closed Issue 24 (https://github.com/netmod-wg/yang-next/issues/24) *add a 'backwards-compatibility' leaf to 'revision' statement?* Proposed marking non-backwards-compatible changes in revision history to aid clients. Considered part of versioning work (issue #45) and closed as a duplicate. * *Github Labels*: Duplicate * *Status*: closed Issue 25 (https://github.com/netmod-wg/yang-next/issues/25) *make yang more object-oriented* Suggested an object-oriented modeling approach where configuration resembles methods. Commenters felt this would be a different language and referenced limited traction in prior work. Closed. * *Github Labels*: complexity-high, backcompat-low, importance-low, No support * *Status*: closed Issue 26 (https://github.com/netmod-wg/yang-next/issues/26) *Consider removing support for sub modules from YANG* Thread on NETMOD is 'Query about augmenting module from submodule in YANG 1.0'. Juergen: In case YANG 2.0 is ever done, I suggest someone files a proposal to remove submodules if the cost/benefit ratio is at odds. * *Github Labels*: complexity-low, backcompat-low, importance-low * *Status*: open Wilton Expires 18 September 2026 [Page 29] Internet-Draft YANG Next Agreement March 2026 Issue 27 (https://github.com/netmod-wg/yang-next/issues/27) *Clarify YANG "status" keyword usage (e.g., hierarchical)* This issue requests: Clarify YANG "status" keyword usage (e.g., hierarchical). * *Github Labels*: complexity-low, backcompat-high, importance-high * *Status*: open Issue 28 (https://github.com/netmod-wg/yang-next/issues/28) *add 'status' as a sub statement to 'module'* So that an entire module (routing-cfg) can be deprecated w/o having to deprecate every node. * *Github Labels*: complexity-low, backcompat-high, importance-med * *Status*: open Issue 29 (https://github.com/netmod-wg/yang-next/issues/29) *Clarify YANG validation for data nodes 'decoded' from anydata to a tree of real nodes* Raised how offline validation tools should interpret anydata/anyxml in RPC inputs or configs and suggested using schema mount. Replies said this is a tooling concern and schema mount is not appropriate. Closed. * *Github Labels*: complexity-low, importance-low, Not a YANG Issue, Tooling issue * *Status*: closed Issue 30 (https://github.com/netmod-wg/yang-next/issues/30) *key-predicate-expr should be (quoted-string / integer-value / decimal-value)* Proposed errata to allow numeric literals in instance-identifier key predicates instead of requiring quoted strings. The errata was withdrawn due to implementation impact, deferring the topic to YANG 2.0. Closed. Wilton Expires 18 September 2026 [Page 30] Internet-Draft YANG Next Agreement March 2026 * *Github Labels*: complexity-low, backcompat-low, importance-low, Not an issue after all * *Status*: closed Issue 31 (https://github.com/netmod-wg/yang-next/issues/31) *Add 'clone' statement* Suggested a clone statement to copy existing schema nodes instead of defining reusable groupings. Concerns included misuse, clone loops, and increased complexity; the proposal was withdrawn. Closed. * *Github Labels*: complexity-high, importance-low, No support * *Status*: closed Issue 32 (https://github.com/netmod-wg/yang-next/issues/32) *Allow Augmentation to Groupings* Proposed augmenting groupings directly so additions apply to all uses, avoiding repeated augment statements. Implementation and safety concerns dominated the discussion. Closed with no support. * *Github Labels*: complexity-high, backcompat-low, No support * *Status*: closed Issue 33 (https://github.com/netmod-wg/yang-next/issues/33) *Tag YANG identity as an intermediate base for classification only* Some identity definitions are not intended to be actual values, but rather used as intermediate base definitions. YANG automation tools need a way to identify these nodes in a machine-readable manner. * *Github Labels*: complexity-low, backcompat-high, importance-high * *Status*: open Issue 34 (https://github.com/netmod-wg/yang-next/issues/34) *Add native support for float/double* Wilton Expires 18 September 2026 [Page 31] Internet-Draft YANG Next Agreement March 2026 Add support for IEEE 754 binary floats and doubles. routing- types.yang (RFC 8294) defines bandwidth-ieee-float32, but ends up using a string as the base type (fine for text based encoding schemes, not so great for binary encoding schemes). * *Github Labels*: complexity-med, backcompat-high, importance-high * *Status*: open Issue 35 (https://github.com/netmod-wg/yang-next/issues/35) *Simplify 'when' statement processing* Proposed removing automatic deletion of nodes when when conditions become false due to complexity and NACM concerns. Discussion favored keeping current behavior and noted that offline validation does not involve request processing. Closed. * *Github Labels*: Undesirable outcome * *Status*: closed Issue 36 (https://github.com/netmod-wg/yang-next/issues/36) *enable leafrefs to uniquely reference a nested list* Given the following data model: and a desire to uniquely reference a specific "bar": ` It's not possible unless all the "bar" names are globally unique (not just for the current "foo"). * *Github Labels*: backcompat-high, importance-high, complexity- unknown * *Status*: open Issue 37 (https://github.com/netmod-wg/yang-next/issues/37) *YANG ANBF could be defined in a simpler way* Suggested a simplified ABNF that separates generic statement structure from argument validation for parser convenience. Responses noted the simplified grammar already exists in section 6.3 and that changing ABNF would be risky for low benefit. Closed. * *Github Labels*: backcompat-high, importance-low, Undesirable outcome * *Status*: closed Wilton Expires 18 September 2026 [Page 32] Internet-Draft YANG Next Agreement March 2026 Issue 38 (https://github.com/netmod-wg/yang-next/issues/38) *Allow action to be invoked in the context of configuration datastore* Requested allowing actions on configuration datastores to support batch edits or complex operations. The discussion debated semantics and usefulness versus existing edit-config capabilities. Closed without adopting the change. * *Github Labels*: Undesirable outcome * *Status*: closed Issue 39 (https://github.com/netmod-wg/yang-next/issues/39) *Allow deviation for description* Deviations can modify the meaning and content of a data node. However it is not possible to update relevant the description statement. * *Github Labels*: complexity-low, backcompat-high, importance-high * *Status*: open Issue 40 (https://github.com/netmod-wg/yang-next/issues/40) *Allow deviation for Identities* It should be possible to declare that I do not support specific identities in a module. E.g. * *Github Labels*: backcompat-high, importance-high, complexity- unknown * *Status*: open Issue 41 (https://github.com/netmod-wg/yang-next/issues/41) *Allow some references to from config-true to config-false (add capabilities)* IN some cases it would be needed to allow referencing config=false data from config=true leafrefs. E.g. * *Github Labels*: complexity-high, importance-med, backcompat- unknown Wilton Expires 18 September 2026 [Page 33] Internet-Draft YANG Next Agreement March 2026 * *Status*: open Issue 42 (https://github.com/netmod-wg/yang-next/issues/42) *make schema-mount extension into a built-in statement* Proposed integrating schema-mount as a core language statement. Comments advised gaining more experience and using critical extensions if needed. Closed. * *Github Labels*: complexity-med, backcompat-low, importance-low, Workaround is better * *Status*: closed Issue 43 (https://github.com/netmod-wg/yang-next/issues/43) *Support for multiple keys in a list* Asked for multiple key statements on a list to allow alternate unique access paths. Discussion noted optional keys were rejected and recommended using two lists with a shared grouping, despite drawbacks for config and augment. Closed. * *Github Labels*: Not a YANG Issue, NETCONF issue * *Status*: closed Issue 44 (https://github.com/netmod-wg/yang-next/issues/44) *Clarify if multiple deviations target the same schema parts* This issue tracks the request titled 'Clarify if multiple deviations target the same schema parts'. * *Github Labels*: complexity-low, backcompat-high, importance-high * *Status*: open Issue 45 (https://github.com/netmod-wg/yang-next/issues/45) *Refine YANG versioning* This issue tracks the request titled 'Refine YANG versioning'. * *Github Labels*: backcompat-low, importance-high, complexity- unknown Wilton Expires 18 September 2026 [Page 34] Internet-Draft YANG Next Agreement March 2026 * *Status*: open Issue 46 (https://github.com/netmod-wg/yang-next/issues/46) *Binary encoding support (lets some types have binary persistence)* The YANG to CBOR encoding algorithms use binary types for some YANG data types. For example, enumerations are sent using the value number and bits are sent as a number with bits set corresponding to the position number. * *Github Labels*: importance-high, backcompat-unknown, complexity- unknown, Not a YANG Issue, Workaround is better, NETMOD issue, NETCONF issue * *Status*: open Issue 47 (https://github.com/netmod-wg/yang-next/issues/47) *support external module requirements* Suggested requires/provides statements to express dependencies beyond import (e.g., augment relationships, common type modules). Reviewers indicated this belongs in YANG library or package definitions. Closed. * *Github Labels*: Not a YANG Issue, NETMOD issue, NETCONF issue * *Status*: closed Issue 48 (https://github.com/netmod-wg/yang-next/issues/48) *when using a grouping, the designer should be able to modify just about any aspect of the grouping* Proposed broad modification capabilities for groupings (removing nodes, disabling if-feature) instead of copy/paste. Concerns focused on complexity and layering effects. Closed as an undesirable outcome. * *Github Labels*: importance-low, backcompat-unknown, complexity- unknown, Undesirable outcome * *Status*: closed Wilton Expires 18 September 2026 [Page 35] Internet-Draft YANG Next Agreement March 2026 Issue 49 (https://github.com/netmod-wg/yang-next/issues/49) *Introduce critical extensions* Critical extensions would be allowed to extend or modify YANG semantics and would be mandatory to implement. In fact, some existing extensions, such as *yang-data*, are already of this category, even though RFC 7950 only permits extensions to address _non-YANG semantics_. * *Github Labels*: complexity-high, importance-med, backcompat- unknown * *Status*: open Issue 50 (https://github.com/netmod-wg/yang-next/issues/50) *YANG Packages (multi-module conformance/guidance)* Requested a machine-readable way to define packages of modules with version/feature requirements. Discussion suggested this is better handled by YANG library or instance data documents and pursued in a separate draft, not the YANG language itself. Closed as not a YANG issue. * *Github Labels*: Not a YANG Issue, NETMOD issue * *Status*: closed Issue 51 (https://github.com/netmod-wg/yang-next/issues/51) *A general way to add stmts to any part of a schema* As a vendor we sometimes want to extend a YANG model by annotating it with extra metadata information. E.g. * *Github Labels*: backcompat-high, importance-low, complexity- unknown * *Status*: open Issue 52 (https://github.com/netmod-wg/yang-next/issues/52) *add a statement for modeling checkbox dialogs* Wilton Expires 18 September 2026 [Page 36] Internet-Draft YANG Next Agreement March 2026 Proposed a statement to model multi-select checkbox dialogs, similar to choice for radio buttons. Alternatives included using optional leafs, bits, or UI annotations/overlays. Closed with preference for the overlay/annotation solution. * *Github Labels*: complexity-low, backcompat-high, importance-low, Workaround is better * *Status*: closed Issue 53 (https://github.com/netmod-wg/yang-next/issues/53) *Create a way for a statement to tie-in with augment/deviation* RFC7950 section 7.19 specifically says: ` An extension can allow refinement (see Section 7.13.2) and deviations (Section 7.20.3.2), but the mechanism for how this is defined is outside the scope of this specification.` Via refine this extends to augment and uses. * *Github Labels*: complexity-med, importance-low, backcompat- unknown, Need Examples / Use Case * *Status*: open Issue 54 (https://github.com/netmod-wg/yang-next/issues/54) *Define a way for extensions to declare sub-statement validity* RFC7950 leaves this capability out in section 7.19: ` The substatements of an extension are defined by the "extension" statement, using some mechanism outside the scope of this specification. Syntactically, the substatements MUST be YANG statements, including extensions defined using "extension" statements. * *Github Labels*: complexity-med, backcompat-high, importance-med * *Status*: open Issue 55 (https://github.com/netmod-wg/yang-next/issues/55) *define an encoding-independent "ypath:1.0" type* Discussed the need for a context-independent encoding of XPath expressions and YANG types, avoiding prefix-to-namespace reliance. The conclusion was that this can be addressed in RFC6991bis by making XPath 1.0 context independent, without changing YANG. Closed. Wilton Expires 18 September 2026 [Page 37] Internet-Draft YANG Next Agreement March 2026 * *Github Labels*: Workaround is better, Undesirable outcome * *Status*: closed Issue 56 (https://github.com/netmod-wg/yang-next/issues/56) *context-independent encoding of instance-identifiers and identityrefs* In the XML encoding of an instance-identifier or an identityref, there are prefixes that are supposed to be defined in the XML document. This means that there is no canonical format of these values. * *Github Labels*: complexity-med, backcompat-low, importance-high * *Status*: open Issue 57 (https://github.com/netmod-wg/yang-next/issues/57) *introduce if-module* it would be useful to have a statement "if-module" that can be used like if-feature: leaf my-interface { if-module ietf-interfaces; type if:interface-ref; }. * *Github Labels*: complexity-low, backcompat-high, importance- unknown, Need Examples / Use Case * *Status*: open Issue 58 (https://github.com/netmod-wg/yang-next/issues/58) *Introduce XPath function datastore()* The expression datastore(name) would select the root node of datastore name, where name is the name of a datastore. YANG rules for accessible trees are sometimes too limiting. * *Github Labels*: complexity-high, backcompat-high, importance-low * *Status*: open Issue 59 (https://github.com/netmod-wg/yang-next/issues/59) *Preliminary Status* Wilton Expires 18 September 2026 [Page 38] Internet-Draft YANG Next Agreement March 2026 Sometimes we deliver features to customers before they are stable, to give them a working preview of functionality. For this we use the following extension statement extension preliminary { description "The schema node is part of an early design effort. * *Github Labels*: complexity-low, backcompat-high, importance-med * *Status*: open Issue 60 (https://github.com/netmod-wg/yang-next/issues/60) *Allowing module private groupings, typedefs* Within a module. top level groupings and typedefs are externally visible and reusable by other modules, whereas local groupings and typedefs are private to the module, and can be changed in a BC way. * *Github Labels*: complexity-low, backcompat-high, importance-med * *Status*: open Issue 61 (https://github.com/netmod-wg/yang-next/issues/61) *Make NACM default-deny-all and default-deny-write built-in statements* Ready to promote these to language statements so it is not NACM- specific. * *Github Labels*: complexity-low, backcompat-high, importance-med * *Status*: open Issue 62 (https://github.com/netmod-wg/yang-next/issues/62) *Currently, list keys are all mandatory - allows default values for keys.* This issue tracks the request titled 'Currently, list keys are all mandatory - allows default values for keys.'. * *Github Labels*: backcompat-high, importance-med, complexity- unknown * *Status*: open Wilton Expires 18 September 2026 [Page 39] Internet-Draft YANG Next Agreement March 2026 Issue 63 (https://github.com/netmod-wg/yang-next/issues/63) *Should it be possible to deviate "status"?* Should it be possible for an implementation to modify the status of a datanode? E.g. * *Github Labels*: complexity-med, backcompat-high, importance-med * *Status*: open Issue 64 (https://github.com/netmod-wg/yang-next/issues/64) *Clarify if double quotes are needed around identifiers* Questioned whether identifiers need quotes when used as string arguments (e.g., defaults). Discussion concluded that quoting is optional when no whitespace or special characters are present and that the grammar should remain permissive; pretty printers may normalize. Closed as not a YANG issue. * *Github Labels*: Not a YANG Issue, NETMOD issue * *Status*: closed Issue 65 (https://github.com/netmod-wg/yang-next/issues/65) *Require implementation of "status deprecated" data nodes* We should change YANG (with some sensible migration path) to require servers to implement status deprecated data nodes or otherwise use explicit deviations to indicate that the data nodes are not implemented. * *Github Labels*: complexity-low, backcompat-high, importance-high * *Status*: open Issue 66 (https://github.com/netmod-wg/yang-next/issues/66) *Require that "status obsolete" nodes are not implemented* We should consider changing YANG (with some sensible migration path) to require servers to not implement "status obsolete" nodes or otherwise use a explicit deviation mechanism to indicate that the data noes are still implemented and present in the schema. * *Github Labels*: complexity-low, backcompat-low, importance-med Wilton Expires 18 September 2026 [Page 40] Internet-Draft YANG Next Agreement March 2026 * *Status*: open Issue 67 (https://github.com/netmod-wg/yang-next/issues/67) *clarify "require-instance" property for leafrefs* Asked when require-instance is evaluated and how errors are reported for delete operations of referenced nodes. Responses pointed to existing text (sections 8.3.3 and 15.5) covering these cases. Closed with no change required. * *Github Labels*: Not an issue after all * *Status*: closed Issue 68 (https://github.com/netmod-wg/yang-next/issues/68) *Add if-feature on must stmt (removed "on import stmt" part)* When designing the IGMP Proxy model, I feel it needs adding if- feature in import stmt and must stmt. But it doesn't support now. * *Github Labels*: complexity-med, backcompat-high, importance-low * *Status*: open Issue 69 (https://github.com/netmod-wg/yang-next/issues/69) *Clarify 'deviation' substatements to match ABNF grammar* As mentioned in: The current table in RFC7950, Section 7.20.3.2 lists all permitted substatements however each argument to "delete" is treated separately per ABNF. If we are not going to add other possible substatements (e.g. * *Github Labels*: complexity-low, backcompat-high, importance-high * *Status*: open Issue 70 (https://github.com/netmod-wg/yang-next/issues/70) *Introduce support for critical annotations* Similar to #49, but for annotations (RFC 7952), so that something like Juniper's "inactive" annotation can be introduced without requiring a new version of YANG. Wilton Expires 18 September 2026 [Page 41] Internet-Draft YANG Next Agreement March 2026 * *Github Labels*: backcompat-unknown, complexity-unknown, importance-unknown, Need Examples / Use Case * *Status*: open Issue 71 (https://github.com/netmod-wg/yang-next/issues/71) *extension-stmt conformance* The conformance requirements and capabilities discovery for extension statements is broken and implementations do not follow it. If a module contains extensions and a server advertises the implemented module in the YANG library, then the server must implement all extensions in the module. * *Github Labels*: backcompat-unknown, complexity-unknown, importance-unknown, Need Examples / Use Case * *Status*: open Issue 72 (https://github.com/netmod-wg/yang-next/issues/72) *Introduce an annotation that resolves the union member* Determining the union member to be used for a given instance is a fragile and potentially demanding process that may also depend on the instance representation. The (optional) annotation would pinpoint the member type so that no guesswork is needed. * *Github Labels*: complexity-med, importance-high, backcompat- unknown * *Status*: open Issue 73 (https://github.com/netmod-wg/yang-next/issues/73) *Initial value* 3GPP is starting to use YANG for modeling. The "default value" as defined by 3GPP is actually an initial value. * *Github Labels*: complexity-med, importance-med * *Status*: open Wilton Expires 18 September 2026 [Page 42] Internet-Draft YANG Next Agreement March 2026 Issue 74 (https://github.com/netmod-wg/yang-next/issues/74) *Support for unique leaf (or leaf combo) in a list of lists* If I have a list which has a container, I can specify a leaf to be unique or a combination of leaf nodes to be unique. e.g.: If I have a list of lists, I know of no way to have a leaf inside the lower list to be delcared unique across all lists. * *Github Labels*: complexity-med, importance-low * *Status*: open Issue 75 (https://github.com/netmod-wg/yang-next/issues/75) *Deprecate "import by exact revision"* Using YANG import with an exact revision date is invariably the wrong thing to do and I propose that it should be removed from the next version of the language (but allowed for modules using yang-version 1.1). * *Github Labels*: complexity-low, importance-high * *Status*: open Issue 76 (https://github.com/netmod-wg/yang-next/issues/76) *Make submodule "include" statement require a revision date.* A particular module revision should be a precisely defined immutable instance of a YANG module. However, allowing submodule includes to not specify the revision of the submodules that they include allows this to be broken. * *Github Labels*: importance-med, complexity-unknown * *Status*: open Issue 77 (https://github.com/netmod-wg/yang-next/issues/77) *Add support for a tuple type* Sometimes it is desirable to group multiple leaves together into the same value type that is available on a single path. Adding native support for something like a tuple type might be an elegant way of solving this, rather than the current approach of using an adhoc string based tuple type. Wilton Expires 18 September 2026 [Page 43] Internet-Draft YANG Next Agreement March 2026 * *Github Labels*: complexity-high, importance-high * *Status*: open Issue 78 (https://github.com/netmod-wg/yang-next/issues/78) *allow 'must' as a sub statement to 'grouping'* The crypto-types:asymmetric-key-pair-grouping grouping is a "container-less" grouping (a grouping that defines its descendents directly, without wrapping them with a container), which makes it impossible to define a 'must' statement that spans all its descendents (none of which are "mandatory true"). * *Github Labels*: importance-low * *Status*: open Issue 79 (https://github.com/netmod-wg/yang-next/issues/79) *add 'unique' as a substatement to 'leaf-list'* The request sought a unique substatement for leaf-lists. The discussion noted RFC7950 already requires uniqueness for configuration leaf-lists, and the issue was closed as not applicable. * *Github Labels*: Not an issue after all * *Status*: closed Issue 80 (https://github.com/netmod-wg/yang-next/issues/80) *enable a server express conformance to a set of identifiers* This issue requests: enable a server express conformance to a set of identifiers. * *Github Labels*: importance-high * *Status*: open Issue 81 (https://github.com/netmod-wg/yang-next/issues/81) *let 'description' be a substatement to 'input' and 'output'* It would be nice to have a description statement to describe what a collection of input/output descendent nodes are for. Wilton Expires 18 September 2026 [Page 44] Internet-Draft YANG Next Agreement March 2026 * *Github Labels*: complexity-low, importance-med * *Status*: open Issue 82 (https://github.com/netmod-wg/yang-next/issues/82) *enable features to be supported per grouping-use (not globally per- datastore)* I'm unsure if this is a YANG Next, YANG library, or a modeling issue... Use case: a shared low-level module defines a feature and defines a grouping with an if-feature with it. * *Github Labels*: complexity-high, importance-low * *Status*: open Issue 83 (https://github.com/netmod-wg/yang-next/issues/83) *Clarify canonical representation of typedefs* Some typedefs (and possibly some leaves) (e.g. ipv6-prefix) define their own canonical representation of the value space that overrides the canonical representation defined in the YANG built in types (RFC 7950 section 9.1). * *Github Labels*: importance-high, complexity-unknown * *Status*: open Issue 84 (https://github.com/netmod-wg/yang-next/issues/84) *allow notifications/actions to appear in invalid contexts* For example, RFC 7950 Section 7.16 says: But sometimes a grouping contains a notification or an action, and thus is currently disqualified from being _used_ inside (in this case) a notification. * *Github Labels*: complexity-low, backcompat-high, importance-high * *Status*: open Issue 85 (https://github.com/netmod-wg/yang-next/issues/85) *add "uses" as a sub-statement to "augment"* Asked to allow reuse of identical augment blocks via a uses substatement. Closed because this is already supported in YANG 1.1. Wilton Expires 18 September 2026 [Page 45] Internet-Draft YANG Next Agreement March 2026 * *Github Labels*: none * *Status*: closed Issue 86 (https://github.com/netmod-wg/yang-next/issues/86) *allow 'case' as a substatement to 'grouping'* Sometimes there is a need to augment the same case statement into multiple choice statements. Ideally the case statement itself could also be defined in the grouping statement. * *Github Labels*: importance-low * *Status*: open Issue 87 (https://github.com/netmod-wg/yang-next/issues/87) *enable specifying augmentation's location amongst siblings* Requested control over the placement of augmented nodes in resolved trees or diagram output. Comments noted YANG is unordered and enforcing order would be a large change; tooling could handle presentation. Closed. * *Github Labels*: none * *Status*: closed Issue 88 (https://github.com/netmod-wg/yang-next/issues/88) *clarify NP-containers* Searching the NETCONF list archives for the word "non-presense" found the following: * 2019-06-21: restconf 'get' on non-presence container * 2018-06-28: Existence of Non-Presence Containers * 2016-07-11: What should a server response be? * *Github Labels*: complexity-low, importance-med * *Status*: open Issue 89 (https://github.com/netmod-wg/yang-next/issues/89) *add 'recommended-default' statement* Wilton Expires 18 September 2026 [Page 46] Internet-Draft YANG Next Agreement March 2026 It is important to maintain backward compatibility with existing program behavior. Often the YANG default is not the recommended setting, but rather the setting that matches current program behavior. * *Github Labels*: importance-low * *Status*: open Issue 90 (https://github.com/netmod-wg/yang-next/issues/90) *Have a mechanism to allow enums to be extended* I think that in some cases, individuals writing YANG modules end up using identities instead of enums because they want to leave the door open to them being extended in future. * *Github Labels*: importance-high, complexity-unknown * *Status*: open Issue 91 (https://github.com/netmod-wg/yang-next/issues/91) *Consider relaxing identity uniqueness to only require uniqueness with the base identity hierarchy* _Flagging this only because it came up as a discussion point on yang- doctors._ Currently identities must be unique within a module. So, in the case of loopback, this meant that I originally defined "loopback-internal", "loopback-line", "loopback-connector" as descendants of base identity "loopback" to avoid namespace collisions. * *Github Labels*: complexity-high, importance-low * *Status*: open Issue 92 (https://github.com/netmod-wg/yang-next/issues/92) *enable if-feature statements to be "refined" into notifications and actions* A grouping can define a data tree, as well as notifications, actions. The refine statement can add if-feature statements to many types of data nodes, but not for actions or notifications. * *Github Labels*: complexity-low, importance-high Wilton Expires 18 September 2026 [Page 47] Internet-Draft YANG Next Agreement March 2026 * *Status*: open Issue 93 (https://github.com/netmod-wg/yang-next/issues/93) *support 'dynamic default'* if a leaf node can not be defined a static default value, but it has a uncertain default value when it is created. For example: If list 'foo' is created, if leaf named 'type''s value is foo1, the default value of leaf named 'value' is 10, if leaf named 'type''s value is foo2, the default value of leaf named 'value' is 20. * *Github Labels*: complexity-high, importance-low * *Status*: open Issue 94 (https://github.com/netmod-wg/yang-next/issues/94) *deref() function for leafref statements* This issue requests: deref() function for leafref statements. * *Github Labels*: complexity-low, importance-high * *Status*: open Issue 95 (https://github.com/netmod-wg/yang-next/issues/95) *Allow an module import to be defined as "types only"* Today, when a module imports another module it isn't made explicit whether that import is to fulfill a path or identity dependency or simply for a typedef dependency. Whilst working on YANG packages, I've began to think that it might be helpful to allow import statements to be annotated to indicate that it only imports type definitions, making the relationship between YANG modules a bit more clear. * *Github Labels*: importance-high * *Status*: open Issue 96 (https://github.com/netmod-wg/yang-next/issues/96) *Clarify definitions of YANG schema tree, vs module schema tree* Wilton Expires 18 September 2026 [Page 48] Internet-Draft YANG Next Agreement March 2026 The following errata was proposed (but likely rejected) for RFC 7950: Original Text ------------- o schema tree: The definition hierarchy specified within a module. Corrected Text -------------- o schema tree: The hierarchy of schema nodes defined in the set of all modules implemented by a server, as specified in the YANG library data . * *Github Labels*: complexity-low, backcompat-high, importance-med * *Status*: open Issue 97 (https://github.com/netmod-wg/yang-next/issues/97) *enable 'ordered-by' to be refined into a list or leaf-list* A grouping may define a list or leaf-list and, for whatever reason, the using model wished to change the 'ordered-by' value. This should be allowed, right? * *Github Labels*: none * *Status*: open Issue 98 (https://github.com/netmod-wg/yang-next/issues/98) *Disallow if-feature statements where enabling the feature removes data nodes from the schema* The expressions for if-feature nodes should not be allowed to remove nodes from the tree when a feature is enabled because it makes conformance for clients very complex. E.g. * *Github Labels*: backcompat-low, importance-unknown * *Status*: open Issue 99 (https://github.com/netmod-wg/yang-next/issues/99) *Clarify duplicate revision dates used in revision history* The RFC does not mention any error condition if multiple revision- stmts have the same revision-date value. This occurs in openconfig- inet-types.yang and other real modules. * *Github Labels*: importance-med * *Status*: open Wilton Expires 18 September 2026 [Page 49] Internet-Draft YANG Next Agreement March 2026 Issue 100 (https://github.com/netmod-wg/yang-next/issues/100) *Add errata-stmt to YANG* There needs to be a way to specify the known Errata corrections to a YANG module. There are many published modules with bugs. * *Github Labels*: importance-high * *Status*: open Issue 101 (https://github.com/netmod-wg/yang-next/issues/101) *allow 'require-instance' to be refined* It would be nice to leafref (inside a grouping)'s require-instance property. This to compliment when the list the leafref refers to was itself refined from config true to config false. * *Github Labels*: complexity-low, backcompat-high, importance-med * *Status*: open Issue 102 (https://github.com/netmod-wg/yang-next/issues/102) *ascii vs. unicode strings* Per Alexey Melnikov's DISCUSS on the module-tags draft, though the issue is a long-standing one... * *Github Labels*: importance-low * *Status*: open Issue 103 (https://github.com/netmod-wg/yang-next/issues/103) *Clarify implicit 'case' behavior* Implicit case statements have some interesting undocumented behavior:. * *Github Labels*: complexity-low, backcompat-high, importance-med * *Status*: open Wilton Expires 18 September 2026 [Page 50] Internet-Draft YANG Next Agreement March 2026 Issue 104 (https://github.com/netmod-wg/yang-next/issues/104) *clarify "instance-required" behavior in typedefs* As discussed in authors expect that the require-instance statement is available not only for leafref and instance-identifier types, but also for all the types derived from them using typedef statement. * *Github Labels*: complexity-low, backcompat-high, importance-high * *Status*: open Issue 105 (https://github.com/netmod-wg/yang-next/issues/105) *remove the "anyxml" statement* *Synopsis:* The "anyxml" statement was made in RFC 6020, before JSON support was added, but its value is questionable now... Propose to remove (if YANG-next == YANG 2.0) or deprecate (if YANG-next == YANG 1.2). * *Github Labels*: complexity-low, importance-med, backcompat- unknown * *Status*: open Issue 106 (https://github.com/netmod-wg/yang-next/issues/106) *Allow "input/output" to be defined without any child data nodes* Change the ABNF to allow an input and output statements to be defined without any data nodes (e.g. in the case that models are expected to augment the input/output statement). * *Github Labels*: complexity-low, backcompat-high, importance-med * *Status*: open Issue 107 (https://github.com/netmod-wg/yang-next/issues/107) *Add deviate(not-supported) support for identities* There is no way for a server vendor to tell the YANG client that a specific identity in a YANG module is not supported. This is critical for vendors who use YANG modules defined by an SDO (all of them) YANG conformance for identities is particularly awful at this time because it mandates that every identity in a supported module be implemented. Wilton Expires 18 September 2026 [Page 51] Internet-Draft YANG Next Agreement March 2026 * *Github Labels*: complexity-med, importance-high * *Status*: open Issue 108 (https://github.com/netmod-wg/yang-next/issues/108) *Allow when in notification* It seems the when statement should be supported also for the notification statement with the exact same justification as for action (. * *Github Labels*: importance-med, backcompat-unknown, complexity- unknown * *Status*: open Issue 109 (https://github.com/netmod-wg/yang-next/issues/109) *Change and compatibility rules for config=false (state) data* Allowed changes and what is compatible should be specified differently for config=true and config=false data. E.g. * *Github Labels*: complexity-high, importance-med * *Status*: open Issue 110 (https://github.com/netmod-wg/yang-next/issues/110) *Clarify canonical order in RFC 7950* RFC 7950 states this: The ABNF grammar defines the canonical order. But the ABNF also has sections that state: ;; these stmts can appear in any order These two statements seem to cause some confusion, and hence it might be helpful to clarify that the ";; these stmts can appear in any order" does not remove the need to list statements in the order listed in the ABNF for them to be regarded as being in canonical order. * *Github Labels*: complexity-low, backcompat-high, importance-med * *Status*: open Issue 111 (https://github.com/netmod-wg/yang-next/issues/111) *Clarify whether revision-dates must be unique or not* Wilton Expires 18 September 2026 [Page 52] Internet-Draft YANG Next Agreement March 2026 RFC 7950 does not explicitly state whether two different revisions of a module can be published with the same date. There is an example of an OpenConfig YANG module that has published multiple revisions with the same revision date, and the OpenConfig proponents state that RFC 7950 does not disallow this. * *Github Labels*: complexity-low, backcompat-high, importance-high * *Status*: open Issue 112 (https://github.com/netmod-wg/yang-next/issues/112) *Support for conditional default values* This issue tracks the request titled 'Support for conditional default values'. * *Github Labels*: importance-low * *Status*: open Issue 113 (https://github.com/netmod-wg/yang-next/issues/113) *Treat if-feature which references a non-existing feature as valid YANG but not enabled* Scenario: A software product comes out with a YANG model. It supports extensions referencing its model. * *Github Labels*: importance-med * *Status*: open Issue 114 (https://github.com/netmod-wg/yang-next/issues/114) *Don't treat non-exist import module as a error if there is no any effective reference to this import module in current module* Suggested not requiring imported modules when deviations remove all effective references. Reviewers said this is not implementable because deviations are separate modules and prefixes used at parse time must resolve. Closed as non-implementable. * *Github Labels*: none * *Status*: closed Wilton Expires 18 September 2026 [Page 53] Internet-Draft YANG Next Agreement March 2026 Issue 115 (https://github.com/netmod-wg/yang-next/issues/115) *Clarify the meaning of properties which have default value* Some statements have default value, such as config/mandatory/min- elements/max-elements/status etc. if these statements are not occur under parent nodes, and should we think the parent nodes have these properties actually? * *Github Labels*: complexity-med, importance-high * *Status*: open Issue 116 (https://github.com/netmod-wg/yang-next/issues/116) *Clarify the behavior if the schema nodes in XPath expression are un- supported* If the schema nodes in XPath expression are un-supported by deviation, should the YANG parser report error? If YANG parser report error, user have to also change the XPath expression by deviation (if its when, it can not be deviated.) If YANG parser dont report error, the evaluation of XPath expression MAY cause unexpected result. * *Github Labels*: complexity-med, backcompat-high, importance-med * *Status*: open Issue 117 (https://github.com/netmod-wg/yang-next/issues/117) *Add dynamic feature to YANG* YANG provide the capability to define data model statically. But it can not meet the requirements of some scenarios: Some nodes are associated with licenses. * *Github Labels*: importance-low * *Status*: open Issue 118 (https://github.com/netmod-wg/yang-next/issues/118) *Co-existence between YANG1.0 and YANG1.1* Wilton Expires 18 September 2026 [Page 54] Internet-Draft YANG Next Agreement March 2026 Argued that YANG 1.0 modules should be able to import YANG 1.1 modules and that RFC7950 has protocol-specific language. Responses emphasized that YANG 1.0 semantics must apply to all imports and that new keywords complicate this. Closed with consensus to keep current rules, though protocol wording could be generalized. * *Github Labels*: none * *Status*: closed Issue 119 (https://github.com/netmod-wg/yang-next/issues/119) *The next step of XPath* Scenarios: The expression of when/must of YANG using XPath 1.0 is not readable and error-prone. The XPath filtering of NETCONF has the same problem. * *Github Labels*: complexity-high, importance-med * *Status*: open Issue 120 (https://github.com/netmod-wg/yang-next/issues/120) *allow more restriction on Identity-ref* Proposed permit/deny substatements under identityref base to exclude specific derived identities. Discussion favored a simpler restriction mechanism and noted overlap with other issues. Closed as a duplicate. * *Github Labels*: none * *Status*: closed Issue 121 (https://github.com/netmod-wg/yang-next/issues/121) *Add support for hierarchical default values* Hierarchical configuration is often expressed in YANG models. In this model, only the "default" statement should be placed at the root of the hierarchical configuration, and all other nodes in the configuration hierarchy must not have a default statement, and instead are required to state in text that the default value is inherited from the next node up in the hierarchical config chain. * *Github Labels*: importance-med, Need Examples / Use Case Wilton Expires 18 September 2026 [Page 55] Internet-Draft YANG Next Agreement March 2026 * *Status*: open Issue 122 (https://github.com/netmod-wg/yang-next/issues/122) *Changing an identity base* Since, as explained in section 7.18.2 of RFC7950, the derivation of identities is transitive, replacing a "base" statement with new "base" statement which is derived from the previous one is also a BC change. * *Github Labels*: importance-med, complexity-unknown * *Status*: open Issue 123 (https://github.com/netmod-wg/yang-next/issues/123) *Allow identities to be active even when module is not implemented* Currently a module has to be implemented in order for its identities to be active. Why is this so? * *Github Labels*: importance-high * *Status*: open Issue 124 (https://github.com/netmod-wg/yang-next/issues/124) *Add ability to deviate or change status of an identity* E.g., for deprecated security protocols, a server should be able to indicate which ones it supports (although this could also be done via a capabilities YANG module). * *Github Labels*: importance-high * *Status*: open Issue 125 (https://github.com/netmod-wg/yang-next/issues/125) *Further restrict YANG Unicode to exclude "del" and C0 control characters* See Unicode Assignables, section 4.3, that defines the table of Unicode assignable characters. This matches what is in RFC 7950, 'yang-char', page 209, except that YANG allows characters in the range %x20-D7FF, but draft-bray-unichars-07 splits this into two ranges to also exclude C1 control characters and DEL: It would Wilton Expires 18 September 2026 [Page 56] Internet-Draft YANG Next Agreement March 2026 probably be helpful for the next version of YANG to be updated to also exclude these characters, and perhaps reference one of the "Character Repertoires", if that draft-bray-unichars progresses. * *Github Labels*: complexity-low * *Status*: open Issue 126 (https://github.com/netmod-wg/yang-next/issues/126) *Injection of circular imports by deviation* RFC 7950 is unclear on whether import dependencies may be introduced by way of deviations. According to RFC 7950: This is clear and I believe most people find this reasonable enough. * *Github Labels*: importance-high * *Status*: open Issue 127 (https://github.com/netmod-wg/yang-next/issues/127) *Relax rules for identityref representation without a prefix* Problem There are several YANG modules that have must/when XPath that compares an identityref leaf to a string literal. uses terminal-otn- protocol-top { when "config/logical-channel-type = 'PROT_OTN'" { description "Include the OTN protocol data only when the channel is using OTN framing."; } } The strict rules in the RFC (sec 9.10) say that the identity (e.g. * *Github Labels*: complexity-low, backcompat-high, importance-med * *Status*: open Issue 128 (https://github.com/netmod-wg/yang-next/issues/128) *Relax rules on usage of deprecated or obsolete identifiers* sec 7.21.2 Issue 1) these MUST requirements make a YANG module brittle and hard to change Issue 2) "deprecated" status should be treated as MUST implement, so "current" using "deprecated" is just a warning Issue 3) "obsolete" status should be treated as MUST NOT implement, but it actually is SHOULD NOT implement. * *Github Labels*: importance-med * *Status*: open Wilton Expires 18 September 2026 [Page 57] Internet-Draft YANG Next Agreement March 2026 Issue 129 (https://github.com/netmod-wg/yang-next/issues/129) *Enable reusability without groupings* The "grouping" statement is great, but only if the module-designer had the foresight to create groupings, which rarely happens. The YANG Full Embed draft attempts to address this by enabling other nodes in a module (e.g., leaf, container) to be used like a grouping. * *Github Labels*: importance-high * *Status*: open Issue 130 (https://github.com/netmod-wg/yang-next/issues/130) *Add 'deprecated' statement* A new statement is needed to help enforce professional API lifecycle management. The 'deprecated' statement contains information about the associated object which has a status of 'deprecated' The purpose of the statement is to provide machine and human readable instructions about the deprecation and suggest a replacement description: text why the node is deprecated replaced-by: machine- readable identifier to use instead of this identifier TBD: expected timeframe for obsolete status container foo { status deprecated; deprecated { description "This node replaced by new system module"; replaced-by bar; } }. * *Github Labels*: complexity-low, backcompat-high, importance-high * *Status*: open Issue 131 (https://github.com/netmod-wg/yang-next/issues/131) *make annotation a built-in YANG statement* RFC 7952 says: An NBC version of YANG-next can do it. * *Github Labels*: complexity-low, importance-med * *Status*: open Issue 132 (https://github.com/netmod-wg/yang-next/issues/132) *Allow config=true list without a key-stmt* Wilton Expires 18 September 2026 [Page 58] Internet-Draft YANG Next Agreement March 2026 Suggested permitting keyless config lists for cases where the list is only created or replaced as a whole. Opponents cited interoperability and quality issues with keyless lists, while others noted autokey expectations. Closed as a duplicate of another issue. * *Github Labels*: none * *Status*: closed Issue 133 (https://github.com/netmod-wg/yang-next/issues/133) *support for more efficient CBOR representation of strings* There are some strings that could be smaller to encode as binary than the UTF8 representation. Strings such as ipv4-address can be encoded more efficiently n binary YANG to CBOR encoding is being enhanced with some new work to encode some strings in CBOR binary format This should not be done with a hard-wired solution. * *Github Labels*: importance-med * *Status*: open Issue 134 (https://github.com/netmod-wg/yang-next/issues/134) *Apply verified errata and resolve held for document update errata* There are 14 verified errata RFC 7950 Errata There are 2 held for review Held for Document Update Must Do. * *Github Labels*: complexity-low, backcompat-high, importance-high * *Status*: open Issue 135 (https://github.com/netmod-wg/yang-next/issues/135) *Make YANG Semver real statements instead of extensions* YANG Semver It is important that "imports" and other procedures directly related to YANG language processing are mandatory to implement so all tools get the correct results. extensions should be real (mandatory-to-implement) statements and not optional extensions no intent to change Semver work file name issues are not be included in this issue Must Do. * *Github Labels*: complexity-med, importance-med * *Status*: open Wilton Expires 18 September 2026 [Page 59] Internet-Draft YANG Next Agreement March 2026 Issue 136 (https://github.com/netmod-wg/yang-next/issues/136) *Revise Module Update Rules* module update rules Dreaded "Section 11" had caused more trouble than any other section. *NBC Change* New Identifier Not Mandatory WG list discussion has resulted in the following change text change in this section OLD NEW Other refinements may be identified during development Must Do: complexity: medium, bc: low, importance: high. * *Github Labels*: complexity-med, importance-med * *Status*: open Issue 137 (https://github.com/netmod-wg/yang-next/issues/137) *Add validation-rules-stmt to identify YANG validation scope* Proposed a validation-rules statement with strict/relaxed/off modes to handle offline validation, multi-datastore references, or template-like configuration. Discussion questioned the examples and scope, suggesting use of intended datastores, must statements, or presence-like behavior. Closed per the Oct 24 meeting. * *Github Labels*: none * *Status*: closed Issue 138 (https://github.com/netmod-wg/yang-next/issues/138) *Add new node type 'listref'* This is related to tuples #77 A listref is similar to a leafref but it represents the keys or position that identtify one list instance A listref is a terminal node like a leaf or a leaf-list or anydata A listref works the same no matter how many key leafs are defined for the list *Full Representation* no -keys: position of the list entry keys: leaf matching each leaf in the key-stmt *Short Representation* no-keys: use uint32 keys: use TBD tuple from #77 solution Example target grouping Pointed-at list: Listref A listref value example. * *Github Labels*: importance-high * *Status*: open Wilton Expires 18 September 2026 [Page 60] Internet-Draft YANG Next Agreement March 2026 Issue 139 (https://github.com/netmod-wg/yang-next/issues/139) *Clarify adding mandatory nodes with augment + when* augments para 7 example is not valid since old client knows about values 1 .. 5 for toasterWeight. * *Github Labels*: complexity-low, backcompat-high, importance-med * *Status*: open Issue 140 (https://github.com/netmod-wg/yang-next/issues/140) *grouping usage requirements* There are some design choices that are possible with YANG groupings that need to be considered for the uses-stmt There are documentation guidelines but these are not commonly followed, or complete. * *Github Labels*: complexity-med, importance-med * *Status*: open Issue 141 (https://github.com/netmod-wg/yang-next/issues/141) *Add automatic list key generation (autokey)* There are many use-cases where the list key does not contain any semantics other than being a unique identifier. In this mode, the designer does not want to define or implement the list key management. * *Github Labels*: importance-med * *Status*: open Issue 142 (https://github.com/netmod-wg/yang-next/issues/142) *Allow if-feature on deviations* The issue requested allowing "if-feature" under "deviation" so a single deviation module could cover both feature-enabled and feature- disabled cases. It was closed as a duplicate of issue #2. * *Github Labels*: none * *Status*: closed Wilton Expires 18 September 2026 [Page 61] Internet-Draft YANG Next Agreement March 2026 Issue 143 (https://github.com/netmod-wg/yang-next/issues/143) *Allow deviation-stmt within uses-stmt* Sometimes an existing grouping is almost usable in a new us-case. YANG 1.1 allows some refinements in the 'uses' expansion, but no deviations. * *Github Labels*: complexity-med, importance-med * *Status*: open Issue 144 (https://github.com/netmod-wg/yang-next/issues/144) *YANG 1.1 translation* A standard translation from YANG 2.0 to YANG 1.1 should be defined. It will be difficult to introduce YANG 2.0 modules if a YANG 1.1 version cannot be automatically generated for existing tools to use. * *Github Labels*: complexity-low, importance-high * *Status*: open Issue 145 (https://github.com/netmod-wg/yang-next/issues/145) *Let a presence container have a default presence?* A presence container is like a leaf of type boolean. Leafs can have a default have, but not P-containers, why? * *Github Labels*: importance-low * *Status*: open Issue 146 (https://github.com/netmod-wg/yang-next/issues/146) *Consistent default value behavior for operations and validation* YANG validation (e.g., must-stmt) sometimes depends on whether a "node exists in the accessible tree". This creates a cornercase with the default-stmt The issue is that every server can decide differently whether node /npcon/B is in the accessible tree. * *Github Labels*: complexity-low, backcompat-high, importance-high * *Status*: open Wilton Expires 18 September 2026 [Page 62] Internet-Draft YANG Next Agreement March 2026 Issue 147 (https://github.com/netmod-wg/yang-next/issues/147) *New default-system statement to indicate that the default value is not constant (determined by the system)* See which we agreed is of low-importance. When the default is determined by the system (conditions usually mentioned in the description), it'd be handy for tooling to know that such is the case. * *Github Labels*: complexity-low, backcompat-high, importance-med * *Status*: open Issue 148 (https://github.com/netmod-wg/yang-next/issues/148) *YANG++* YANG++ YANG++ is a data modeling language under development. Project Goals Complete the design and specification of the YANG++ language Design and implement open-source plugins - Native compiler support for YANG++ - YANG 1.1 Translation Tool Documentation YANG++ DRAFT. * *Github Labels*: importance-high * *Status*: open Issue 149 (https://github.com/netmod-wg/yang-next/issues/149) *Error statement for actions rpcs* In some cases for rpcs and actions there is a need to supply detailed error information beyond what is specified in RFC 6241. NETCONF allows for additional information in the "error-message" or "error- info" elements, however there is no way to define the structure and syntax of the error message. * *Github Labels*: complexity-low, importance-high * *Status*: open Issue 150 (https://github.com/netmod-wg/yang-next/issues/150) *nbc-change-stmt* There is a need for a new statement to identify an NBC change in an exportable statement. The Semver extension is not helpful since it is at the module-level instead of the object level, This cannot be Wilton Expires 18 September 2026 [Page 63] Internet-Draft YANG Next Agreement March 2026 done with the 'deprecated' statement in #130 since the NBC change is most likely done in a 'current' definition with no intent to deprecate and replace it. * *Github Labels*: none * *Status*: open Issue 151 (https://github.com/netmod-wg/yang-next/issues/151) *YANG profiles and views* There a trend (especially in IETF WGs) to create new YANG models to address some specific use cases rather than re-using existing YANG models because existing YANG models either provides more information than needed for that specific application or the information provided is not formatted as expected by the application Slides presented and discussed during the IETF 121 side meeting: YANG Profiles and Views v00.pptx. * *Github Labels*: none * *Status*: open Issue 152 (https://github.com/netmod-wg/yang-next/issues/152) *YANG-next issue summary* Proposes a method to summarize and prioritize YANG-next issues by grouping and filtering by importance and complexity. * *Github Labels*: none * *Status*: open Issue 153 (https://github.com/netmod-wg/yang-next/issues/153) *Allow 'when' to be a child of the 'refine' statement* Already if-feature and must statements are children under "refine", why not the "when" statement...? * *Github Labels*: none * *Status*: open Wilton Expires 18 September 2026 [Page 64] Internet-Draft YANG Next Agreement March 2026 Issue 154 (https://github.com/netmod-wg/yang-next/issues/154) *Add ability to remove nodes from a grouping in a "uses" statement* This issue requests: Add ability to remove nodes from a grouping in a "uses" statement. * *Github Labels*: none * *Status*: open Issue 155 (https://github.com/netmod-wg/yang-next/issues/155) *Allow hexadecimal notation for enum values* It would be beneficial to allow encoding of the enum value in hexadecimal, example: This is not allowed in YANG 1.1. Howere, default integer values are allowed to be encoded in hexadecimal. * *Github Labels*: none * *Status*: open Issue 156 (https://github.com/netmod-wg/yang-next/issues/156) *canonical forms for strings (aka: the mac-address issue)* mac-address in both IETF and IEEE yang is defined as a string. The canonical representations are not the same. * *Github Labels*: none * *Status*: open Author's Address Robert Wilton Cisco Email: rwilton@cisco.com Wilton Expires 18 September 2026 [Page 65]