



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:<module-name>       |                             |
      +------------------------------+-----------------------------+
      | 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,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

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:<module-name> ?*








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"
   <netmod-bounces@ietf.org on behalf of j.schoenwaelder@jacobs-
   university.de> wrote: > On Tue, Apr 19, 2016 at 09:37:03PM +0200,
   Martin Bjorklund wrote: > > But I like urn:yang:<module-name> 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 <error-info> 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]
