<?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.40 (Ruby 3.3.8) -->


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

]>


<rfc ipr="trust200902" docName="draft-ietf-netconf-error-registries-00" 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="September" day="30"/>

    <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+ZALkdvMyCn0yJ0chUSrMEqMCpk1o0Qx
c+JWzEkBXh+Er9Kp9l5bExYlWE+Or18KU01T5QYix5mBAL9Xxld+QMFVSkCz
h0I6JQdkSy/m1r0dO1uVAzo/vj68OH8p3qoFqPlAUEInJigHLZIjVkoIWYWJ
dbwlCD+jqihqpV8pR0OTK+e9NXHPurE0+r0M0A6aWaMtXS18UFMf99VU6mJA
pXJ9tvVbzSf6Xm3LPtNhUhm6nkhNP8pClhNd7Lji+NdKG/1uXfg0ctbyx0zq
Z3YqhLFuCqYZ4CG6fHn45YMHj5rlowcH+83y8f2D+8vlo4dPVks+ILQZtUJE
v98XIkkSkikcJDMgdT3RnuDTaor4oVyNtEHcnAzPh+S6cRQmipaxEoOIuoEo
dm22YYmb49VTneeFEuIOO83ZvMoYFiFODHCCYyhYmsiZIkmZNAA7kwV5W7lM
RTVkUVCMMx+jPy5Jt9GPM2Ij5GNke/JVNiHplwFEHz40QN7cRFGXx1drGwzr
zc2eCHO7BQfisoEqH/wpJt1NsYUJgkV5tS4aNlOqSL0LCmGaRyFVyTmSs+5G
KVCB5UkgzQiQzGfSBDmu0VkmOKmZLSpGdoXnJpqed+p79hAniHiZkx0Bd68C
L5ZRgYMTGeLVzALtEJ2lLhrtnBopp0wW1bpDh9bM2D7kc9w+Ypx0/OZoU4S8
JU5cT72z11fXvb36L51fxPXl8Q+vTy6Pj3h99f3w9HS1EM2Jq+8vXp8etauW
8/Di7Oz4/KhmBpU6JNE7G77BDmvVu3h1fXJxPjztkQZEnSRg79Z2ai4rpVM1
+CJXPnM6xQd4Xhy++v23/QMEy2eIlgf7+08QRvXH4/2vDvAxnyhT32ZNsWg+
kUULIctSScdSOJozWeogC7/HDvYTOzc0AaJA8/OfGZlfBvQ0zcr9g2cNgQ3u
EJeYdYgRs23KFnMN4g7SjmtWaHboG0h39R2+6XwvcV8jPn1eIJMo2X/8/BmK
BFcGzjcEkkdeO9nEzp07t6da068Wt9UzuUyxxV+Xsiax4R0xhJ9Mrt/RkPNh
rV7ExCUu+7zB4lbycX1vh2zBsns1H/quVnMqbaGzpUJg64jgFgmz+GCvvpmr
f3OzWB31E44gpzIkVNRjZIvCzrUZR7lKouQBCHRvVN+6WCYoFnt0/eKoJaAp
dylezZTTYdGlcjNBkFbvdCFZzWVvQZFpUwMxjGolyVjQ6O5PZ6eEC/29PsQc
xVNlLPhJA0VTPFZ+WfmuthFqwBbemMmi4qRgtlhRUMkwNYRYoXZ4ofXjVqXX
hiMuF6kCVkDm48ePYoXNgOKPNkmFLt8iVNOXBRY4lCX8F80XXdQGNV6iRa3m
Rf1VYg2DSK1R+LXCnBT/atfEa9PzYu2VBSahPJql67Fl/Qd6ApdtA4CYzpOI
26e1w5cq06PYKQ1VRmaZKoNMi8aJ0dcsY9MQkKcW1beUDqkF3/sddgVrk1SP
tyzCQGN8aV3YI1dme/+vhdAUHip5aKW70UVzWxU5N42xMly0VH4P7toyEdoT
smfcBryeloXiiJdtuzYYkXaYHodoM05kwLCQVmHbrf/Z8qepzFv5z2jQqXKN
AtQqsGlf5Fe1QZvcDbkOac0DWVlajzzcFMIwxdyWsTnvunfTOUODWQZhF1v1
8hRf0rDuQLNj6adGstVx/gVrUmfGv4ezQWs74GjzOrw1Iqm9dAeW7fk6YwGk
sXyLQ68JX5Pqj/t7NHeWizO3j+1cruIQiaQco7mUEIgXGnsDHSOb9GPNvbWp
b79m/25r/4tHyKpvi7/Zt9eYb+ve4h92b7q1e4s/7d6NJouoP7fTFxLVp3n6
oFXr0TJK0yLuD/M8Dt5olGu9uv/pWy+/S5vW23xzKxZrrZjWW3HuszJB25jh
Jcy2CGhpcy58lYk1wyHLxUgXULFDQvxXo5HONBRLlh3UY1oqC7nonPwH3MYm
/HLEr7SdXm6h8uTjA1pYgmxZ7qXRhspkqOtjtsIjc5tXbwmQbd5Ro37tJcs2
5xdgRJ41/z9IvH6v6uTh13Qqs7c8MQ+zt8bO8SQbxxeb+DCo/72i8m96I7wt
VO8G7rs4uiC5OgmP/gG6JTsHVxIAAA==

-->

</rfc>

