<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!-- [rfced] Because this document updates RFC 6020, please review the errata reported for RFC 6020 (https://www.rfc-editor.org/errata/rfc6020) and let us know if you confirm our opinion that none of them are relevant to the content of this document. --> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4.4) --> <?rfc strict="yes"?> <?rfc comments="yes"?> <?rfc docmapping="yes"?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-netmod-rfc6020-iana-update-02" number="9890" category="std" consensus="true" submissionType="IETF" updates="6020" obsoletes="" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.30.0 -->version="3" xml:lang="en"> <front> <title abbrev="YANG Module Names">An Update to YANG Module Names Registration</title> <seriesInfoname="Internet-Draft" value="draft-ietf-netmod-rfc6020-iana-update-02"/>name="RFC" value="9890"/> <author fullname="Andy Bierman"> <organization>YumaWorks</organization> <address> <postal><country>USA</country><country>United States of America</country> </postal> <email>andy@yumaworks.com</email> </address> </author> <author fullname="Mohamed Boucadair" role="editor"> <organization>Orange</organization> <address> <postal> <country>France</country> </postal> <email>mohamed.boucadair@orange.com</email> </address> </author> <author fullname="Qin Wu"> <organization>Huawei</organization> <address> <postal> <country>China</country> </postal> <email>bill.wu@huawei.com</email> </address> </author> <date year="2025"month="August" day="07"/> <area>Operations and Management</area> <workgroup>Network Modeling</workgroup>month="October"/> <area>OPS</area> <workgroup>netmod</workgroup> <keyword>NETCONF</keyword> <keyword>RESTCONF</keyword> <keyword>Automation</keyword> <abstract><?line 54?><t>This document amends the IANA guidance on the uniqueness of YANG module and submodule names.</t> <t>The document updates RFC 6020 to clarify how modules and their revisions are handled by IANA.</t> </abstract><note removeInRFC="true"> <name>Discussion Venues</name> <t>Discussion of this document takes place on the Network Modeling Working Group mailing list (netmod@ietf.org), which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/netmod/"/>.</t> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/boucadair/rfc8407bis"/>.</t> </note></front> <middle><?line 60?><section anchor="introduction"> <name>Introduction</name> <t><xref target="RFC6020"/> defines a registry for YANG module and submodule names, called "YANG Module Names" <xref target="IANA-MOD-NAMES"/>.</t> <t>Specifically, IANA considerations to register YANG module and submodule names are specified in <xref section="14" sectionFormat="of" target="RFC6020"/>. These considerations require that all module and submodule names in the registry must be unique. However, the practice followed by IANA is not consistent with that guidance.</t> <t>This document amends the guidance on the uniqueness of names (<xref section="14" sectionFormat="of" target="RFC6020"/>) to comply with the IANA practices for registering modules and their revisions.</t> </section> <section anchor="requirements-notation"> <name>Requirements Notation</name><t>The<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 inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <?line -18?>here. </t> </section> <section anchor="sec-iana"> <name>IANA Considerations</name> <section anchor="sec-update"> <name>Update YANG Parameters Registry</name><t>This document requests IANA to update the reference for<t>IANA has updated the "YANG Module Names" registry under the "YANG Parameters" registry group <xref target="IANA-MOD-NAMES"/> toalsolistto the RFC number that will be assigned tothisdocument.document as an additional reference. This update is needed because the procedure in this document is authoritative for assigning names in that registry.</t> </section> <section anchor="sec-amend"> <name>Revisions of Published Modules</name> <t>This document amends the guidance on the uniqueness of names, initially defined in <xref section="14" sectionFormat="of" target="RFC6020"/>, as follows:</t><dl newline="true"> <dt>OLD:</dt> <dd><t>OLD:</t> <blockquote> <t>All module and submodule names in the registry <bcp14>MUST</bcp14> be unique.</t></dd> <dt/> <dd><t>All XML namespaces in the registry <bcp14>MUST</bcp14> be unique.</t></dd> <dt>NEW:</dt> <dd></blockquote> <t>NEW:</t> <blockquote> <t>Modules and their revisions are maintained in the registry.</t></dd> <dt/> <dd><t>All initial version module and submodule names in the registry <bcp14>MUST</bcp14> be unique.</t></dd> <dt/> <dd><t>All XML namespaces of initial version modules in the registry <bcp14>MUST</bcp14> be unique.</t></dd> <dt/> <dd><t>All module and submodule revisions <bcp14>MUST</bcp14> have the same name as the one in the initial version of the module and submodule.</t></dd> <dt/> <dd><t>All module revisions <bcp14>MUST</bcp14> have the same XML namespace as the initial version of the module.</t></dd> </dl></blockquote> </section> </section> <section anchor="operational-considerations"> <name>Operational Considerations</name> <t>This document aligns an IANA policy with the practice for handling YANG module names (<xref target="sec-amend"/>). As such, there are no new operations or manageability requirements introduced by this document.</t> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>This document defines a new IANA action (<xref target="sec-update"/>) anddefinesan update (<xref target="sec-amend"/>) to an IANA registration procedure defined in <xref target="RFC6020"/>. It does not introduce any new or increased security risks that need to be discussed.</t> </section> </middle> <back> <displayreference target="I-D.ietf-netmod-rfc8407bis" to="YANG-GUIDE"/> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="RFC6020"> <front> <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title> <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/> <date month="October" year="2010"/> <abstract> <t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6020"/> <seriesInfo name="DOI" value="10.17487/RFC6020"/> </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><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name> <reference anchor="IANA-MOD-NAMES" target="https://www.iana.org/assignments/yang-parameters/"> <front> <title>YANG Module Names</title> <author> <organization>IANA</organization> </author> <date/> </front> </reference> <!-- [I-D.ietf-netmod-rfc8407bis] draft-ietf-netmod-rfc8407bis-28 IESG State: RFC Ed Queue (EDIT) as of 09/30/25 --> <referenceanchor="I-D.ietf-netmod-rfc8407bis">anchor="I-D.ietf-netmod-rfc8407bis" target="https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-28"> <front> <title>Guidelines for Authors and Reviewers of Documents Containing YANG Data Models</title> <authorfullname="Andy Bierman"initials="A."surname="Bierman">surname="Bierman" fullname="Andy Bierman"> <organization>YumaWorks</organization> </author> <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair"initials="M." surname="Boucadair">role="editor"> <organization>Orange</organization> </author> <authorfullname="Qin Wu"initials="Q."surname="Wu">surname="Wu" fullname="Qin Wu"> <organization>Huawei</organization> </author> <dateday="5"month="June"year="2025"/> <abstract> <t> This document provides guidelines for authors and reviewers of specifications containing YANG data models, including IANA-maintained modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF Protocol implementations that utilize YANG modules. This document obsoletes RFC 8407. Also, this document updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained modules. </t> </abstract>day="5" year="2025" /> </front> <seriesInfo name="Internet-Draft"value="draft-ietf-netmod-rfc8407bis-28"/>value="draft-ietf-netmod-rfc8407bis-28" /> </reference> </references> </references><?line 129?><section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>The content of this document was part of <xref target="I-D.ietf-netmod-rfc8407bis"/>.</t><t>Mahesh Jethanandani<t><contact fullname="Mahesh Jethanandani"/> suggested to offload this part from <xref target="I-D.ietf-netmod-rfc8407bis"/>. Thanks to Mahesh andKent Watsen<contact fullname="Kent Watsen"/> for the discussion and comments.</t> <t>Thanks toMallory Knodel<contact fullname="Mallory Knodel"/> for thegenartGENART review andBarry Leiba artart<contact fullname="Barry Leiba"/> for the ARTART review.</t> <t>ThanksMike Bishop<contact fullname="Mike Bishop"/> for the IESG review.</t> </section> </back> <!--##markdown-source: H4sIAAAAAAAAA61X727bNhD/zqfg3C/rEDlJF6yd0H9u4rZZYzuNE2RBMQy0 RFlEJFIlqRia4XfZs+zJdkdKsuW4yQrMX0yRx/t/vzsGQUCssBkPaW8g6VUR M8upVfRmMP5ARyouM07HLOeGXvC5MFYzK5TsETabaX4Ht+4R9kgEPOZKVyE1 Nial42lC+svBswNCYhVJIAtprFliA8FtEkhucxUHOomQJhBMssBfCw6eEVPO cmEMiLVVARdPh5fviSzzGdchQaKQREoaLk0JUqwuOQHFfiZMcwYKTgrulTaU yZiOgPmc51zaHlkofTvXqiyAbMwtfqIpPBNy3iO3vIKdOCQ0oOPh5fFk/B6X F8Npux6UVuWOOSHGAvs/WaYk6FhxQwoR0i9WRXvUKG01TwysqrxeWC0iu0cj laMusAOOyVlRgOg/CGGlTZVG0YTCLymzzHttIOOKvhNc50y6I6XnTIq/nBIh vSlzdg1mGHcWqVJajMPVdOA2eM5EFqIfqrcVkKLFpg86kPuSRiqF/5i+U2XE Yib0DnETzeScuwOtMIl4LKzSXeHvgSjim/Jzz7o/a1i/VY7RNzT5LCS9LneI /1iyBRddacepkGxT2ExkWX9Rvk0dsRchlcaw3UHqECGTjS+4dzoYD4LR5CQY D0bDaeh4rX9NtezI+y5hG8KtH5gQOhlbJy6TacIyw7dFMj3nNqSptYUJ9/cX i0Ufa6QPrPYZVMZcuhzar8CJQcE0qGO5NvuEBEFA2QzLNrLOuMtUGEy1Em9Q IJSxoTblTiM6L0WMwaJKus1Siq8ll9wYqhKPCbk3GUsJC9N/YZxMvxbA1/zr 2qcX749d+SOyRBnTIqloqhY1M1+YIE9oCqAijC9WzWkKBxnk4Kxy+vW9QbmI YZeQJxArCDrwiHwJLpc/gCQUtFrRmCdCIm/g6ZCrohDox4yAimQZitwRYLpc dnNjtQKNpgWPRCLwWrXn3YhwJOIWdsBorwJ/VLyz2niOoAQk/nI55c48eniE QVhb2Cfga8O3pWn+tRTAxaYMApxlD0kTPsytg/LSWDpr4t6nH9WC33G9R5Cq wCQSkByJyjI4aMNCIaWksl4RsBICvxA29Ro0KQWe+mbuPZx2XtUfv+2IpwTT SuVFVjWC63xuVDYu9E0QAGIfyrw+ZtaF96KrKzpWtgZ5zG7oCxQbg6G90dX0 srfn/+l44tYXw89XpxfDE1xPPw7OztoFqSmmHydXZyfr1frm8WQ0Go5P/GXY pZ0t0hsNbuAEde5Nzi9PJ+PBWc8HseNZ7Vo4xFFIMLfQgAYxZYbE3ERazHxi vTs+/+dvcKUvmmeHh79C0fiPF4fPj+BjkXLppSmJrnWf4KyKQJ/iTCMXTLCI FcICbgGtoQbqWtKUa4z4T1/QM3+E9OUsKg6PXtcbaHBns/FZZ9P57P7Ovcve iTu2dohpvdnZ3/J0V9/BTee78fvG5ss3MDBwGhy+ePOaeFjC5Dvu1uXyieGR m21WQPOkmbUcIJy3mN2MWVVN7xF0tV08WOTcQGo6SRDssp7cXDUn4H3pClW7 yt2FZW3NlxJ0pGuytS4bRG5K2oF/WHkQeUUzoEM9kA+ivZ/PPAQsoANjNvpW Bdnn6DbM6fu2VNuAaMJ5zGMy4xErjbeq0Crican5/XyHtW+2wro27ordC8NS 34A6ZluT+i4IF227AUQ5L2dgRgoKjmp08DFwSHUvBN+HX3uggLACm0TdmR5B d1dMHmkNzCXLkN6ZgkX8Ve+gtyKTs5OQwDT4ffDuam8N7zWD30dnnh7ZP36J jIfXKHv0SO+G6Uta1hi6ybIRXHuEQofBa/+7JeDP3SL+K7+dCq2tdJdSducT 1IBgJx0DhxvwEGjkbKsBmuH2Lv5bsh+U1rG3EfugLNfb2hcRUHVB6l6OZ1BD GOK6napMRBs9dmMi0H5Ww3rbHHHa3r2uo9XTPh1Anyij1HUTSBVMF6mg6hdU rV9rwDN3jzUGI7ywVTPZ+J4s6snPjyFdOHEYDIVVarz2sInrMRHFOzOZr8ha 6xqBV09dnFpy2cDVlnEIbo2/9MaTeQPAOvW/Oc+dgjqK+2GqtQ+4Vd412HAj eNQauGsa67Qwt8ZDG6Jm3fhjYaLSAGE9Ms9YdIteGUS3Ui1gvp07LwKseKDm 8auee3r0Vn7IgVnODXIuezb9tYA0gyeGO1ku35wGJ/2tN/yLo4PnM2HccDxi MKKm9DcOCkrwHzzeIPLzOfQur6tKkkyx2AtxfBOt8sc5XwK/Wzda1yIwOJ9Q wWtmDZcuJTFHa09gBJCkeW+7cXTNAmAWUOCTxMd/e3XOJSqEJQjux9vvmAay My5mDJLWrk/X7EbilsMDHcagomV0Opx+aAn/BRtRJA1zEQAA[rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </rfc>