<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.34 (Ruby 3.3.8) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>


<rfc ipr="trust200902" docName="draft-pamtv-netconf-error-registries-01" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="YANG Procotol Error Registries">Error List and Error Identities Registries for YANG-driven protocols</title>

    <author fullname="Per Andersson">
      <organization>Ionio Systems</organization>
      <address>
        <email>per.ietf@ionio.se</email>
      </address>
    </author>
    <author fullname="Mithun Thai Valaphil">
      <organization>Equinix</organization>
      <address>
        <email>mithun.ietf@gmail.com</email>
      </address>
    </author>

    <date year="2026" month="July" day="07"/>

    <area>ops</area>
    <workgroup>NETCONF</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<?line 38?>

<t>This document defines IANA registries for the YANG Protocol Error List and
YANG Protocol Error Identities.</t>



    </abstract>



  </front>

  <middle>


<?line 44?>

<section anchor="introduction"><name>Introduction</name>

<t>In order to have a canonical source for all errors and error identities for
YANG-driven procotols such as NETCONF <xref target="RFC6241"/> and RESTCONF <xref target="RFC8040"/>,
two IANA registries are defined: YANG Protocol Error List and YANG Protocol
Error Identities. These registries can be extended and updated as needed.</t>

<t>It is an advantage for protocol evolution to have canonical sources to extend,
instead of a set of documents that need to be compiled and referenced.</t>

</section>
<section anchor="conventions-and-definitions"><name>Conventions and Definitions</name>

<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>

<?line -18?>

</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>

<section anchor="yang-protocol-error-list-registry"><name>YANG Protocol Error List Registry</name>

<t>This document defines a registry for the YANG Protocol Error List defined in
Appendix A of <xref target="RFC6241"/>. The name of the registry is "YANG Protocol Error
List". The review policy for this registry is "IETF Review" <xref target="RFC5226"/>. The
registry shall record the following for each entry:</t>

<t><list style="symbols">
  <t>error-tag, TBD</t>
  <t>error-type, TBD</t>
  <t>error-severity, TBD</t>
  <t>error-info, auxilary information described as data nodes (XML tags).</t>
  <t>Description</t>
  <t>The reference for the document registering the value.</t>
</list></t>

<t>The initial contents of the registry is defined in <xref target="RFC6241"/> and inlined
below:</t>

<figure><artwork><![CDATA[
error-tag:      in-use
error-type:     protocol, application
error-severity: error
error-info:     none
Description:    The request requires a resource that already is in
                use.

error-tag:      invalid-value
error-type:     protocol, application
error-severity: error
error-info:     none
Description:    The request specifies an unacceptable value for one
                or more parameters.

error-tag:      too-big
error-type:     transport, rpc, protocol, application
error-severity: error
error-info:     none
Description:    The request or response (that would be generated) is
                too large for the implementation to handle.

error-tag:      missing-attribute
error-type:     rpc, protocol, application
error-severity: error
error-info:     <bad-attribute> : name of the missing attribute
                <bad-element> : name of the element that is supposed
                  to contain the missing attribute
Description:    An expected attribute is missing.

error-tag:      bad-attribute
error-type:     rpc, protocol, application
error-severity: error
error-info:     <bad-attribute> : name of the attribute w/ bad value
                <bad-element> : name of the element that contains
                  the attribute with the bad value
Description:    An attribute value is not correct; e.g., wrong type,
                out of range, pattern mismatch.
]]></artwork></figure>

</section>
<section anchor="yang-protocol-error-identities-registry"><name>YANG Protocol Error Identities Registry</name>

<t>This document defines a registry for YANG Protocol Error Identities. The name
of the registry is "YANG Protocol Error Identities". The review policy for
this registry is "IETF Review" <xref target="RFC5226"/>. The registry shall record the
following for each entry:</t>

<t><list style="symbols">
  <t>Identity name.</t>
  <t>Base identity, if applicable.</t>
  <t>Additional information.</t>
  <t>The reference for the document registering the value.</t>
</list></t>

<t>The initial contents of the registry is defined in <xref target="RFC8639"/> and <xref target="RFC8641"/>
and inlined below:</t>

<figure><artwork><![CDATA[
dscp-unavailable
encoding-unsupported
filter-unsupported
insufficient-resources
replay-unsupported

filter-unsupported
insufficient-resources
no-such-subscription

no-such-subscription

datastore-not-subscribable
unchanging-selection

period-unsupported
update-too-big
synchronization-size
]]></artwork></figure>

</section>
</section>


  </middle>

  <back>



    <references title='Normative References' anchor="sec-normative-references">



<reference anchor="RFC5226">
  <front>
    <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
    <author fullname="T. Narten" initials="T." surname="Narten"/>
    <author fullname="H. Alvestrand" initials="H." surname="Alvestrand"/>
    <date month="May" year="2008"/>
    <abstract>
      <t>Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t>
      <t>In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t>
      <t>This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="5226"/>
  <seriesInfo name="DOI" value="10.17487/RFC5226"/>
</reference>
<reference anchor="RFC6241">
  <front>
    <title>Network Configuration Protocol (NETCONF)</title>
    <author fullname="R. Enns" initials="R." role="editor" surname="Enns"/>
    <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
    <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/>
    <author fullname="A. Bierman" initials="A." role="editor" surname="Bierman"/>
    <date month="June" year="2011"/>
    <abstract>
      <t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="6241"/>
  <seriesInfo name="DOI" value="10.17487/RFC6241"/>
</reference>
<reference anchor="RFC8040">
  <front>
    <title>RESTCONF Protocol</title>
    <author fullname="A. Bierman" initials="A." surname="Bierman"/>
    <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
    <author fullname="K. Watsen" initials="K." surname="Watsen"/>
    <date month="January" year="2017"/>
    <abstract>
      <t>This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8040"/>
  <seriesInfo name="DOI" value="10.17487/RFC8040"/>
</reference>
<reference anchor="RFC8639">
  <front>
    <title>Subscription to YANG Notifications</title>
    <author fullname="E. Voit" initials="E." surname="Voit"/>
    <author fullname="A. Clemm" initials="A." surname="Clemm"/>
    <author fullname="A. Gonzalez Prieto" initials="A." surname="Gonzalez Prieto"/>
    <author fullname="E. Nilsen-Nygaard" initials="E." surname="Nilsen-Nygaard"/>
    <author fullname="A. Tripathy" initials="A." surname="Tripathy"/>
    <date month="September" year="2019"/>
    <abstract>
      <t>This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8639"/>
  <seriesInfo name="DOI" value="10.17487/RFC8639"/>
</reference>
<reference anchor="RFC8641">
  <front>
    <title>Subscription to YANG Notifications for Datastore Updates</title>
    <author fullname="A. Clemm" initials="A." surname="Clemm"/>
    <author fullname="E. Voit" initials="E." surname="Voit"/>
    <date month="September" year="2019"/>
    <abstract>
      <t>This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8641"/>
  <seriesInfo name="DOI" value="10.17487/RFC8641"/>
</reference>
<reference anchor="RFC2119">
  <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author fullname="S. Bradner" initials="S." surname="Bradner"/>
    <date month="March" year="1997"/>
    <abstract>
      <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="2119"/>
  <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
  <front>
    <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
    <author fullname="B. Leiba" initials="B." surname="Leiba"/>
    <date month="May" year="2017"/>
    <abstract>
      <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="8174"/>
  <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>



    </references>




<?line 175?>

<section numbered="false" anchor="acknowledgments"><name>Acknowledgments</name>

<t>TODO acknowledge.</t>

</section>


  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA71Y23LbNhB9x1dslZekY6px4qaJmiZVbKf1jC+p7XSa6fQB
JCEJEwpgAVCKknG+pd/SL+tZkBJFSe51Gj/Y4AK72D17hZMkEUGHQg2od+yc
dXSqfSBpcqo/T3JlcEArT5dqjD3HyxF23gzPv0typ2fKUOlssJktfE/INHVq
BnG8T68cyMEWjbRWRE9kMqixdYsB+ZALkdvMyCn0yJ0chaSU0zBLjAqZNaNE
MXfiVtxJAWYfhK/SqfZeWxMWJXhPjq9fClNNU+UGIseZgQC/V8ZXfkDBVUpA
tYdCOiUHZEsv5ta9HTtblQM6P74+vDh/Kd6qBaj5QFBCJyYoBy2SI9ZKCFmF
iXW8JQg/o6ooaq1fKUdDkyvnvTVxz7qxNPq9DNAOmlmjLV0tfFBTH/fVVOpi
QKVyfa3C6FvNJ/pebcs+02FSGbqeSE0/ykKWE13suOL410ob/W5d+DRy1vLH
TOpndiqEsW4KphngIbp8efjlgwePmuWjBwf7zfLx/YP7y+Wjh09WSz4gtBm1
QkS/3xciSRKSKRwkMyB1PdGe4NRqigCiXI20QeCcDM+H5LqBFCaKlsESo4i6
kSh2bbZxiZvj1VOd54US4g47zdm8yhgWIU4McIJjKFiayJkiSZk0ADuTBXlb
uUxFNWRRUIwzH8M/Lkm34Y8zYiPmY2h78lU2IemXAUQfPjRA3txEUZfHV2sb
DOvNzZ4Ic7sFB+KygSof/Ckm3U2xhQmCRXm1Lho2U6pIvQsKYZpHIVXJOZKz
7kYpUIHlSSDNCJDMZ9IEOa7RWWY4qZktKkZ2hecmmp536nv2ECeIeJmTHQF3
rwIvllGBgxMZ4tXMAu0QnaUuGu2cGimnTBbVukOH1szYPuRz3D5inHT85mhT
hLwlTlxPvbPXV9e9vfovnV/E9eXxD69PLo+PeH31/fD0dLUQzYmr7y9enx61
q5bz8OLs7Pj8qGYGlTok0TsbvsEOa9W7eHV9cnE+PO2RBkSdJGDv1nZqLiul
UzX4Ilc+czrFB3heHL76/bf9AwTLZ4iWB/v7TxBG9cfj/a8O8DGfKFPfZk2x
aD6RRQshy1JJx1I4mjNZ6iALv8cO9hM7NzQBokDz858ZmV8G9DTNyv2DZw2B
De4Ql5h1iBGzbcoWcw3iDtKOa1ZodugbSHf1Hb7pfC9xXyM+fV4gkyjZf/z8
GYoEVwbONwSSR1472cTOnTu3p1rTsBa31TO5TLHFX5eyJrHhHTGEn0yu39GQ
82GtXsTEJS77vMHiVvJxfW+HbMGyezUfGq9WcyptobOlQmDriOAWCbP4YK++
mat/c7NYHfUTjiCnMiRU1GNki8LOtRlHuUqi5AEItG9U37pYJigWe3T94qgl
oCl3KV7NlNNh0aVyM0GQVu90IVnNZW9BkWlTAzGMaiXJWNDo7k9np4QL/b0+
xBzFU2Us+EkDRVM8Vn5Z+a62EWrAFt6YyaLipGC2WFFQyTA1hFihdnih9eNW
pdeGIy4XqQJWQObjx49ihc2A4o82SYUu3yJU05cFFjiUJfwXzRdd1AY1XqJF
reZF/VViDYNIrVH4tcKcFP9q18Rr0/Ni7ZUFJqE8mqXrsWX9B3oCl20DgJjO
k4jbp7XDlyrTo9gpDVVGZpkqg0yLxonR1yxj0xCQpxbVt5QOqQXf+x12BWuT
VI+3LMJAY3xpXdgjV2Z7/6+F0BQeKnlopbvRRXNbFTk3jbEyXLRUfg/u2jIR
2hOyZ9wGvJ6WheKIl227NhiRdpgeh2gzTmTAsJBWYdut/9nyp6nMW/nPaNCp
co0C1CqwaV/kV7VBm9wNuQ5pzQNZWVqPPNwUwjDF3JaxOe+6d9M5Q4NZBmEX
W/XyFF/SsO5As2Ppp0ay1XH+BWtSZ8a/h7NBazvgaPM6vDUiqb10B5bt+Tpj
AaSxfItDrwlfk+qP+3s0d5aLM7eP7Vyu4hCJpByjuZQQiBcaewMdI5v0Y829
talvP2f/bmv/i0fIqm+Lv9m315hv697iH3ZvurV7iz/t3o0mi6g/t9MXEtWn
efqgVevRMkrTIu4P8zwO3miUa726/+lbL79Lm9bbfHMrFmutmNZbce6zMkHb
mOElzLYIaGlzLnyViTXDIcvFSBdQsUNC/Fejkc40FEuWHdRjWioLueic/Afc
xib8csSvtJ1ebqHy5OMDWliCbFnupdGGymSo62O2wiNzm1dvCZBt3lGjfu0l
yzbnF2BEnjX/P0i8fq/q5OHXdCqztzwxD7O3xs7xJBvHF5v4MKj/vaLyb3oj
vC1U7wbuuzi6ILk6CY/+Adf6vkJYEgAA

-->

</rfc>

