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. |