| rfc9890.original | rfc9890.txt | |||
|---|---|---|---|---|
| Network Modeling A. Bierman | Internet Engineering Task Force (IETF) A. Bierman | |||
| Internet-Draft YumaWorks | Request for Comments: 9890 YumaWorks | |||
| Updates: 6020 (if approved) M. Boucadair, Ed. | Updates: 6020 M. Boucadair, Ed. | |||
| Intended status: Standards Track Orange | Category: Standards Track Orange | |||
| Expires: 8 February 2026 Q. Wu | ISSN: 2070-1721 Q. Wu | |||
| Huawei | Huawei | |||
| 7 August 2025 | October 2025 | |||
| An Update to YANG Module Names Registration | An Update to YANG Module Names Registration | |||
| draft-ietf-netmod-rfc6020-iana-update-02 | ||||
| Abstract | Abstract | |||
| This document amends the IANA guidance on the uniqueness of YANG | This document amends the IANA guidance on the uniqueness of YANG | |||
| module and submodule names. | module and submodule names. | |||
| The document updates RFC 6020 to clarify how modules and their | The document updates RFC 6020 to clarify how modules and their | |||
| revisions are handled by IANA. | revisions are handled by IANA. | |||
| Discussion Venues | ||||
| This note is to be removed before publishing as an RFC. | ||||
| Discussion of this document takes place on the Network Modeling | ||||
| Working Group mailing list (netmod@ietf.org), which is archived at | ||||
| https://mailarchive.ietf.org/arch/browse/netmod/. | ||||
| Source for this draft and an issue tracker can be found at | ||||
| https://github.com/boucadair/rfc8407bis. | ||||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This is an Internet Standards Track document. | |||
| 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 | This document is a product of the Internet Engineering Task Force | |||
| and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
| time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
| material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Further information on | |||
| Internet Standards is available in Section 2 of RFC 7841. | ||||
| This Internet-Draft will expire on 8 February 2026. | Information about the current status of this document, any errata, | |||
| and how to provide feedback on it may be obtained at | ||||
| https://www.rfc-editor.org/info/rfc9890. | ||||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2025 IETF Trust and the persons identified as the | Copyright (c) 2025 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents | |||
| license-info) in effect on the date of publication of this document. | (https://trustee.ietf.org/license-info) in effect on the date of | |||
| Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
| and restrictions with respect to this document. Code Components | carefully, as they describe your rights and restrictions with respect | |||
| extracted from this document must include Revised BSD License text as | to this document. Code Components extracted from this document must | |||
| described in Section 4.e of the Trust Legal Provisions and are | include Revised BSD License text as described in Section 4.e of the | |||
| provided without warranty as described in the Revised BSD License. | Trust Legal Provisions and are provided without warranty as described | |||
| in the Revised BSD License. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction | |||
| 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 | 2. Requirements Notation | |||
| 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 | 3. IANA Considerations | |||
| 3.1. Update YANG Parameters Registry . . . . . . . . . . . . . 3 | 3.1. Update YANG Parameters Registry | |||
| 3.2. Revisions of Published Modules . . . . . . . . . . . . . 3 | 3.2. Revisions of Published Modules | |||
| 4. Operational Considerations . . . . . . . . . . . . . . . . . 4 | 4. Operational Considerations | |||
| 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 | 5. Security Considerations | |||
| 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 6. References | |||
| 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 | 6.1. Normative References | |||
| 6.2. Informative References . . . . . . . . . . . . . . . . . 4 | 6.2. Informative References | |||
| Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 5 | Acknowledgments | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 | Authors' Addresses | |||
| 1. Introduction | 1. Introduction | |||
| [RFC6020] defines a registry for YANG module and submodule names, | [RFC6020] defines a registry for YANG module and submodule names, | |||
| called "YANG Module Names" [IANA-MOD-NAMES]. | called "YANG Module Names" [IANA-MOD-NAMES]. | |||
| Specifically, IANA considerations to register YANG module and | Specifically, IANA considerations to register YANG module and | |||
| submodule names are specified in Section 14 of [RFC6020]. These | submodule names are specified in Section 14 of [RFC6020]. These | |||
| considerations require that all module and submodule names in the | considerations require that all module and submodule names in the | |||
| registry must be unique. However, the practice followed by IANA is | registry must be unique. However, the practice followed by IANA is | |||
| skipping to change at page 3, line 17 ¶ | skipping to change at line 91 ¶ | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
| BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 3. IANA Considerations | 3. IANA Considerations | |||
| 3.1. Update YANG Parameters Registry | 3.1. Update YANG Parameters Registry | |||
| This document requests IANA to update the reference for the "YANG | IANA has updated the "YANG Module Names" registry under the "YANG | |||
| Module Names" registry under the "YANG Parameters" registry group | Parameters" registry group [IANA-MOD-NAMES] to list this document as | |||
| [IANA-MOD-NAMES] to also list to the RFC number that will be assigned | an additional reference. This update is needed because the procedure | |||
| to this document. This update is needed because the procedure in | in this document is authoritative for assigning names in that | |||
| this document is authoritative for assigning names in that registry. | registry. | |||
| 3.2. Revisions of Published Modules | 3.2. Revisions of Published Modules | |||
| This document amends the guidance on the uniqueness of names, | This document amends the guidance on the uniqueness of names, | |||
| initially defined in Section 14 of [RFC6020], as follows: | initially defined in Section 14 of [RFC6020], as follows: | |||
| OLD: | OLD: | |||
| All module and submodule names in the registry MUST be unique. | ||||
| All XML namespaces in the registry MUST be unique. | | All module and submodule names in the registry MUST be unique. | |||
| | | ||||
| | All XML namespaces in the registry MUST be unique. | ||||
| NEW: | NEW: | |||
| Modules and their revisions are maintained in the registry. | ||||
| All initial version module and submodule names in the registry | ||||
| MUST be unique. | ||||
| All XML namespaces of initial version modules in the registry MUST | ||||
| be unique. | ||||
| All module and submodule revisions MUST have the same name as the | ||||
| one in the initial version of the module and submodule. | ||||
| All module revisions MUST have the same XML namespace as the | | Modules and their revisions are maintained in the registry. | |||
| initial version of the module. | | | |||
| | All initial version module and submodule names in the registry | ||||
| | MUST be unique. | ||||
| | | ||||
| | All XML namespaces of initial version modules in the registry MUST | ||||
| | be unique. | ||||
| | | ||||
| | All module and submodule revisions MUST have the same name as the | ||||
| | one in the initial version of the module and submodule. | ||||
| | | ||||
| | All module revisions MUST have the same XML namespace as the | ||||
| | initial version of the module. | ||||
| 4. Operational Considerations | 4. Operational Considerations | |||
| This document aligns an IANA policy with the practice for handling | This document aligns an IANA policy with the practice for handling | |||
| YANG module names (Section 3.2). As such, there are no new | YANG module names (Section 3.2). As such, there are no new | |||
| operations or manageability requirements introduced by this document. | operations or manageability requirements introduced by this document. | |||
| 5. Security Considerations | 5. Security Considerations | |||
| This document defines a new IANA action (Section 3.1) and defines an | This document defines a new IANA action (Section 3.1) and an update | |||
| update (Section 3.2) to an IANA registration procedure defined in | (Section 3.2) to an IANA registration procedure defined in [RFC6020]. | |||
| [RFC6020]. It does not introduce any new or increased security risks | It does not introduce any new or increased security risks that need | |||
| that need to be discussed. | to be discussed. | |||
| 6. References | 6. References | |||
| 6.1. Normative References | 6.1. Normative References | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/rfc/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for | [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for | |||
| the Network Configuration Protocol (NETCONF)", RFC 6020, | the Network Configuration Protocol (NETCONF)", RFC 6020, | |||
| DOI 10.17487/RFC6020, October 2010, | DOI 10.17487/RFC6020, October 2010, | |||
| <https://www.rfc-editor.org/rfc/rfc6020>. | <https://www.rfc-editor.org/info/rfc6020>. | |||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
| May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
| 6.2. Informative References | 6.2. Informative References | |||
| [I-D.ietf-netmod-rfc8407bis] | ||||
| Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for | ||||
| Authors and Reviewers of Documents Containing YANG Data | ||||
| Models", Work in Progress, Internet-Draft, draft-ietf- | ||||
| netmod-rfc8407bis-28, 5 June 2025, | ||||
| <https://datatracker.ietf.org/doc/html/draft-ietf-netmod- | ||||
| rfc8407bis-28>. | ||||
| [IANA-MOD-NAMES] | [IANA-MOD-NAMES] | |||
| IANA, "YANG Module Names", | IANA, "YANG Module Names", | |||
| <https://www.iana.org/assignments/yang-parameters/>. | <https://www.iana.org/assignments/yang-parameters/>. | |||
| [YANG-GUIDE] | ||||
| Bierman, A., Boucadair, M., Ed., and Q. Wu, "Guidelines | ||||
| for Authors and Reviewers of Documents Containing YANG | ||||
| Data Models", Work in Progress, Internet-Draft, draft- | ||||
| ietf-netmod-rfc8407bis-28, 5 June 2025, | ||||
| <https://datatracker.ietf.org/doc/html/draft-ietf-netmod- | ||||
| rfc8407bis-28>. | ||||
| Acknowledgments | Acknowledgments | |||
| The content of this document was part of | The content of this document was part of [YANG-GUIDE]. | |||
| [I-D.ietf-netmod-rfc8407bis]. | ||||
| Mahesh Jethanandani suggested to offload this part from | Mahesh Jethanandani suggested to offload this part from [YANG-GUIDE]. | |||
| [I-D.ietf-netmod-rfc8407bis]. Thanks to Mahesh and Kent Watsen for | Thanks to Mahesh and Kent Watsen for the discussion and comments. | |||
| the discussion and comments. | ||||
| Thanks to Mallory Knodel for the genart review and Barry Leiba artart | Thanks to Mallory Knodel for the GENART review and Barry Leiba for | |||
| review. | the ARTART review. | |||
| Thanks Mike Bishop for the IESG review. | Thanks Mike Bishop for the IESG review. | |||
| Authors' Addresses | Authors' Addresses | |||
| Andy Bierman | Andy Bierman | |||
| YumaWorks | YumaWorks | |||
| United States of America | United States of America | |||
| Email: andy@yumaworks.com | Email: andy@yumaworks.com | |||
| End of changes. 23 change blocks. | ||||
| 90 lines changed or deleted | 76 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. | ||||