rfc9907.original   rfc9907.txt 
Network Modeling A. Bierman Internet Engineering Task Force (IETF) A. Bierman
Internet-Draft YumaWorks Request for Comments: 9907 YumaWorks
Obsoletes: 8407 (if approved) M. Boucadair, Ed. BCP: 216 M. Boucadair, Ed.
Updates: 8126 (if approved) Orange Obsoletes: 8407 Orange
Intended status: Best Current Practice Q. Wu Updates: 8126 Q. Wu
Expires: 7 December 2025 Huawei Category: Best Current Practice Huawei
5 June 2025 ISSN: 2070-1721 January 2026
Guidelines for Authors and Reviewers of Documents Containing YANG Data Guidelines for Authors and Reviewers of Documents Containing YANG Data
Models Models
draft-ietf-netmod-rfc8407bis-28
Abstract Abstract
This document provides guidelines for authors and reviewers of This document provides guidelines for authors and reviewers of
specifications containing YANG data models, including IANA-maintained specifications containing YANG data models, including IANA-maintained
modules. Recommendations and procedures are defined, which are YANG modules. Recommendations and procedures are defined, which are
intended to increase interoperability and usability of Network intended to increase interoperability and usability of Network
Configuration Protocol (NETCONF) and RESTCONF Protocol Configuration Protocol (NETCONF) and RESTCONF protocol
implementations that utilize YANG modules. This document obsoletes implementations that utilize YANG modules.
RFC 8407.
Also, this document updates RFC 8126 by providing additional
guidelines for writing the IANA considerations for RFCs that specify
IANA-maintained modules.
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 This document obsoletes RFC 8407; it also updates RFC 8126 by
https://github.com/boucadair/rfc8407bis. providing additional guidelines for writing the IANA considerations
for RFCs that specify IANA-maintained YANG modules.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This memo documents an Internet Best Current Practice.
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
BCPs is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 7 December 2025. 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/rfc9907.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction
1.1. Changes Since RFC 8407 . . . . . . . . . . . . . . . . . 6 1.1. Changes Since RFC 8407
2. Terminology & Notation Conventions . . . . . . . . . . . . . 8 2. Terminology and Notation Conventions
2.1. NETCONF Terms . . . . . . . . . . . . . . . . . . . . . . 9 2.1. NETCONF Terms
2.2. YANG Terms . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. YANG Terms
2.3. Network Management Datastore Architecture (NMDA) Terms . 9 2.3. Network Management Datastore Architecture (NMDA) Terms
2.4. Requirements Notation . . . . . . . . . . . . . . . . . . 10 2.4. Requirements Notation
2.5. YANG Data Model vs. YANG Module . . . . . . . . . . . . . 10 2.5. YANG Data Model versus YANG Module
3. General Documentation Guidelines . . . . . . . . . . . . . . 11 3. General Documentation Guidelines
3.1. Module Copyright . . . . . . . . . . . . . . . . . . . . 11 3.1. Module Copyright
3.2. Code Components . . . . . . . . . . . . . . . . . . . . . 12 3.2. Code Components
3.2.1. Example Modules . . . . . . . . . . . . . . . . . . . 12 3.2.1. Example Modules
3.3. Terminology Section . . . . . . . . . . . . . . . . . . . 13 3.3. Terminology Section
3.4. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 13 3.4. Tree Diagrams
3.5. Narrative Sections . . . . . . . . . . . . . . . . . . . 13 3.5. Narrative Sections
3.5.1. YANG Module Classification . . . . . . . . . . . . . 14 3.5.1. YANG Module Classification
3.6. Definitions Section . . . . . . . . . . . . . . . . . . . 15 3.6. Definitions Section
3.7. Security Considerations Section . . . . . . . . . . . . . 15 3.7. Security Considerations Section
3.7.1. Security Considerations Section Template . . . . . . 16 3.7.1. Security Considerations Section Template
3.8. IANA Considerations Section . . . . . . . . . . . . . . . 19 3.8. IANA Considerations Section
3.8.1. Documents That Create a New Namespace . . . . . . . . 19 3.8.1. Documents That Create a New Namespace
3.8.2. Documents That Extend an Existing Namespace . . . . . 19 3.8.2. Documents That Extend an Existing Namespace
3.8.3. Registration Templates . . . . . . . . . . . . . . . 19 3.8.3. Registration Templates
3.9. References Sections . . . . . . . . . . . . . . . . . . . 20 3.9. References Sections
3.10. Validation Tools . . . . . . . . . . . . . . . . . . . . 21 3.10. Validation Tools
3.11. Module Extraction Tools . . . . . . . . . . . . . . . . . 21 3.11. Module Extraction Tools
3.12. Module Usage Examples . . . . . . . . . . . . . . . . . . 22 3.12. Module Usage Examples
4. YANG Usage Guidelines . . . . . . . . . . . . . . . . . . . . 23 4. YANG Usage Guidelines
4.1. Module Naming Conventions . . . . . . . . . . . . . . . . 23 4.1. Module Naming Conventions
4.2. Prefixes . . . . . . . . . . . . . . . . . . . . . . . . 24 4.2. Prefixes
4.3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 25 4.3. Identifiers
4.3.1. Identifier Naming Conventions . . . . . . . . . . . . 25 4.3.1. Identifier Naming Conventions
4.4. Defaults . . . . . . . . . . . . . . . . . . . . . . . . 26 4.4. Defaults
4.5. Conditional Statements . . . . . . . . . . . . . . . . . 27 4.5. Conditional Statements
4.6. XPath Usage . . . . . . . . . . . . . . . . . . . . . . . 31 4.6. XPath Usage
4.6.1. XPath Evaluation Contexts . . . . . . . . . . . . . . 31 4.6.1. XPath Evaluation Contexts
4.6.2. Function Library . . . . . . . . . . . . . . . . . . 32 4.6.2. Function Library
4.6.3. Axes . . . . . . . . . . . . . . . . . . . . . . . . 33 4.6.3. Axes
4.6.4. Types . . . . . . . . . . . . . . . . . . . . . . . . 33 4.6.4. Types
4.6.5. Wildcards . . . . . . . . . . . . . . . . . . . . . . 34 4.6.5. Wildcards
4.6.6. Boolean Expressions . . . . . . . . . . . . . . . . . 35 4.6.6. Boolean Expressions
4.7. YANG Definition Lifecycle Management . . . . . . . . . . 36 4.7. YANG Definition Lifecycle Management
4.8. Module Header, Meta, and Revision Statements . . . . . . 37 4.8. Module Header, Meta, and Revision Statements
4.9. Namespace Assignments . . . . . . . . . . . . . . . . . . 39 4.9. Namespace Assignments
4.10. Top-Level Data Definitions . . . . . . . . . . . . . . . 41 4.10. Top-Level Data Definitions
4.11. Data Types . . . . . . . . . . . . . . . . . . . . . . . 41 4.11. Data Types
4.11.1. Fixed-Value Extensibility . . . . . . . . . . . . . 42 4.11.1. Fixed-Value Extensibility
4.11.2. Patterns and Ranges . . . . . . . . . . . . . . . . 43 4.11.2. Patterns and Ranges
4.11.3. Enumerations and Bits . . . . . . . . . . . . . . . 44 4.11.3. Enumerations and Bits
4.11.4. Union Types . . . . . . . . . . . . . . . . . . . . 44 4.11.4. Union Types
4.11.5. Empty and Boolean . . . . . . . . . . . . . . . . . 46 4.11.5. Empty and Boolean
4.12. Reusable Type Definitions . . . . . . . . . . . . . . . . 47 4.12. Reusable Type Definitions
4.13. Reusable Groupings . . . . . . . . . . . . . . . . . . . 47 4.13. Reusable Groupings
4.14. Data Definitions . . . . . . . . . . . . . . . . . . . . 48 4.14. Data Definitions
4.14.1. Non-Presence Containers . . . . . . . . . . . . . . 49 4.14.1. Non-Presence Containers
4.14.2. Top-Level Data Nodes . . . . . . . . . . . . . . . . 50 4.14.2. Top-Level Data Nodes
4.15. Operation Definitions . . . . . . . . . . . . . . . . . . 50 4.15. Operation Definitions
4.16. Notification Definitions . . . . . . . . . . . . . . . . 51 4.16. Notification Definitions
4.17. Feature Definitions . . . . . . . . . . . . . . . . . . . 51 4.17. Feature Definitions
4.18. YANG Data Node Constraints . . . . . . . . . . . . . . . 52 4.18. YANG Data Node Constraints
4.18.1. Controlling Quantity . . . . . . . . . . . . . . . . 52 4.18.1. Controlling Quantity
4.18.2. "must" versus "when" . . . . . . . . . . . . . . . . 53 4.18.2. "must" versus "when"
4.19. "augment" Statements . . . . . . . . . . . . . . . . . . 53 4.19. "augment" Statements
4.19.1. Conditional Augment Statements . . . . . . . . . . . 53 4.19.1. Conditional Augment Statements
4.19.2. Conditionally Mandatory Data Definition 4.19.2. Conditionally Mandatory Data Definition Statements
Statements . . . . . . . . . . . . . . . . . . . . . 54 4.20. Deviation Statements
4.20. Deviation Statements . . . . . . . . . . . . . . . . . . 55 4.21. Extension Statements
4.21. Extension Statements . . . . . . . . . . . . . . . . . . 56 4.22. Data Correlation
4.22. Data Correlation . . . . . . . . . . . . . . . . . . . . 57 4.22.1. Use of "leafref" for Key Correlation
4.22.1. Use of "leafref" for Key Correlation . . . . . . . . 58 4.23. Operational State
4.23. Operational State . . . . . . . . . . . . . . . . . . . . 59 4.23.1. Combining Operational State and Configuration Data
4.23.1. Combining Operational State and Configuration 4.23.2. Representing Operational Values of Configuration Data
Data . . . . . . . . . . . . . . . . . . . . . . . . 60 4.23.3. NMDA Transition Guidelines
4.24. Performance Considerations
4.23.2. Representing Operational Values of Configuration 4.25. Open Systems Considerations
Data . . . . . . . . . . . . . . . . . . . . . . . . 60 4.26. Guidelines for Constructs Specific to YANG 1.1
4.23.3. NMDA Transition Guidelines . . . . . . . . . . . . . 61 4.26.1. Importing Multiple Revisions
4.24. Performance Considerations . . . . . . . . . . . . . . . 64 4.26.2. Using Feature Logic
4.25. Open Systems Considerations . . . . . . . . . . . . . . . 65 4.26.3. "anyxml" versus "anydata"
4.26. Guidelines for Constructs Specific to YANG 1.1 . . . . . 65 4.26.4. "action" versus "rpc"
4.26.1. Importing Multiple Revisions . . . . . . . . . . . . 65 4.27. Updating YANG Modules (Published versus Unpublished)
4.26.2. Using Feature Logic . . . . . . . . . . . . . . . . 65 4.28. Defining Standard Tags
4.26.3. "anyxml" versus "anydata" . . . . . . . . . . . . . 66 4.29. Modeling Abstract Data Structures
4.26.4. "action" versus "rpc" . . . . . . . . . . . . . . . 66 4.30. IANA-Maintained Modules
4.27. Updating YANG Modules (Published versus Unpublished) . . 67 4.30.1. Context
4.28. Defining Standard Tags . . . . . . . . . . . . . . . . . 67 4.30.2. Guidelines for IANA-Maintained Modules
4.29. Modeling Abstract Data Structures . . . . . . . . . . . . 68
4.30. IANA-Maintained Modules . . . . . . . . . . . . . . . . . 68
4.30.1. Context . . . . . . . . . . . . . . . . . . . . . . 68
4.30.2. Guidelines for IANA-Maintained Modules . . . . . . . 69
4.30.3. Guidance for Writing the IANA Considerations for RFCs 4.30.3. Guidance for Writing the IANA Considerations for RFCs
Defining IANA-Maintained Modules . . . . . . . . . . 71 Defining IANA-Maintained Modules
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 78 5. IANA Considerations
5.1. YANG Modules . . . . . . . . . . . . . . . . . . . . . . 79 5.1. YANG Modules
5.2. Update YANG Parameters Registry Group . . . . . . . . . . 79 5.2. Update in YANG Parameters Registry Group
5.3. IANA-Maintained Modules . . . . . . . . . . . . . . . . . 79 5.3. IANA-Maintained Modules
6. Operations and Manageability Considerations . . . . . . . . . 80 6. Operations and Manageability Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 80 7. Security Considerations
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 80 8. References
8.1. Normative References . . . . . . . . . . . . . . . . . . 80 8.1. Normative References
8.2. Informative References . . . . . . . . . . . . . . . . . 82 8.2. Informative References
Appendix A. Module Review Checklist . . . . . . . . . . . . . . 87 Appendix A. Module Review Checklist
Appendix B. Template for IETF Modules . . . . . . . . . . . . . 89 Appendix B. Template for IETF Modules
Appendix C. Template for IANA-Maintained Modules . . . . . . . . 91 Appendix C. Template for IANA-Maintained Modules
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 93 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 94 Authors' Addresses
1. Introduction 1. Introduction
The standardization of network configuration interfaces for use with The standardization of network configuration interfaces for use with
network configuration management protocols, such as the Network network configuration management protocols, such as the Network
Configuration Protocol (NETCONF) [RFC6241] and the RESTCONF Protocol Configuration Protocol (NETCONF) [RFC6241] and RESTCONF [RFC8040],
[RFC8040], requires a modular set of data models that can be reused requires a modular set of data models that can be reused and extended
and extended over time. over time.
This document defines a set of guidelines for documents containing This document defines a set of guidelines for documents containing
YANG 1.1 [RFC7950] and YANG 1.0 [RFC6020] data models, including YANG 1.1 [RFC7950] and YANG 1.0 [RFC6020] data models, including
IANA-maintained modules. YANG is used to define the data structures, IANA-maintained YANG modules. YANG is used to define the data
protocol operations, and notification content used within a NETCONF structures, protocol operations, and notification content used within
and/or RESTCONF server. YANG is also used to define abstract data a NETCONF and/or RESTCONF server. YANG is also used to define
structures [RFC8791]. A NETCONF or RESTCONF server that supports a abstract data structures [RFC8791]. A NETCONF or RESTCONF server
particular YANG module will support client NETCONF and/or RESTCONF that supports a particular YANG module will support client NETCONF
operation requests, as indicated by the specific content defined in and/or RESTCONF operation requests, as indicated by the specific
the YANG module. content defined in the YANG module.
Many YANG constructs are defined as optional to use, such as the Many YANG constructs are defined as optional to use, such as the
"description" statement. However, in order to make YANG modules more "description" statement. However, in order to make YANG modules more
readable and interoperable, it is desirable to define a set of readable and interoperable, it is desirable to define a set of
descriptive usage guidelines that entails a higher level of descriptive usage guidelines that entails a higher level of
compliance than the minimum level defined in the YANG specification compliance than the minimum level defined in the YANG specification
[RFC7950]. [RFC7950].
In addition, YANG allows constructs such as infinite length In addition, YANG allows constructs such as infinite length
identifiers and string values, or top-level mandatory nodes, that a identifiers and string values, or top-level mandatory nodes, that a
compliant server is not required to support. Only constructs that compliant server is not required to support. Only constructs that
all servers are required to support can be used in IETF YANG modules. all servers are required to support can be used in IETF YANG modules.
This document defines usage guidelines related to the NETCONF This document defines usage guidelines related to the NETCONF
operations layer and NETCONF content layer, as defined in [RFC6241], operations layer and NETCONF content layer, as defined in [RFC6241],
and the RESTCONF methods and RESTCONF resources, as defined in and the RESTCONF methods and RESTCONF resources, as defined in
[RFC8040]. [RFC8040].
These guidelines are intended to be used by authors and reviewers to These guidelines are intended to be used by authors and reviewers to
improve the readability and interoperability of published YANG data improve the readability and interoperability of published YANG data
models. These guidelines can be used independent of the IETF models. These guidelines can be used independent of the IETF Stream
publication stream or even by other organizations. of publication or even by other organizations.
YANG 1.0 modules have to conform to [RFC6020] while YANG 1.1 modules YANG 1.0 modules have to conform to [RFC6020] while YANG 1.1 modules
have to conform to [RFC7950]. This document adds usage guidelines in have to conform to [RFC7950]; this document adds usage guidelines in
addition to these YANG RFCs. addition to these RFCs.
Section 4.30.3 updates [RFC8126] by providing guidance for writing Section 4.30.3 updates [RFC8126] by providing guidance for writing
the IANA considerations for RFCs that specify IANA-maintained the IANA Considerations sections for RFCs that specify IANA-
modules. maintained YANG modules.
Note that this document is not a YANG tutorial, and the reader is Note that this document is not a YANG tutorial; the reader is
expected to know the YANG data modeling language before implementing expected to know the YANG data modeling language before implementing
the guidance in this document. the guidance in this document.
Note to the RFC Editor: Please replace "AAAA" through the document
with the RFC number assigned to this document.
1.1. Changes Since RFC 8407 1.1. Changes Since RFC 8407
The following changes have been made to the guidelines published in The following changes have been made to the guidelines published in
[RFC8407]: [RFC8407]:
* Implemented errata 5693, 5800, 6899, and 7416. * Implemented the following errata reports: [Err5693], [Err5800],
[Err6899], and [Err7416].
* Updated the terminology. * Updated the terminology.
* Added a note about notation conventions. * Added a note about notation conventions.
* Updated the URL of the IETF authors guidelines. * Updated the reference information of the IETF author guidelines.
* Updated the guidance so that the "file name" after the <CODE * Updated the guidance so that the "file name" after the <CODE
BEGINS> tag is mandatory. BEGINS> tag is mandatory.
* Added code markers for the security template. * Added code markers for the security template.
* Updated the YANG security considerations template to better insist * Updated the YANG security considerations template to better insist
on the key secure transport features. on the key secure transport features.
* Added statements that the security template is not required for * Added statements that the security template is not required for
modules that follow [RFC8791] or [RFC7952]. modules that follow [RFC8791] or [RFC7952].
* Added a statement about how to cite the RFCs that are listed in * Added a statement about how to cite the RFCs that are listed in
the security template. the security template.
* Added a template for IANA registrations. * Added a template for IANA registrations.
* Added a note that folding of the examples should be done as per * Added a note that folding of the examples should be done as per
[RFC8792] conventions. the conventions described in [RFC8792].
* Added a recommendation about long trees. * Added a recommendation about long trees.
* Fixed a reference bug in Section 4.1. * Fixed a reference bug in Section 4.1.
* Added a recommendation for the use of meaningful prefix values. * Added a recommendation for the use of meaningful prefix values.
* Added a note that RFC8792-folding of YANG modules can be used if * Added a note that folding of YANG modules as described in RFC 8792
and only if built-in YANG features (e.g., break line, "+") are not can be used if and only if built-in YANG features (e.g., break
sufficient. line, "+") are not sufficient.
* Added tool validation checks to ensure that YANG modules fit into * Added tool validation checks to ensure that YANG modules fit into
the line limits of an I-D. the line limits of an I-D.
* Added tool validation checks of JSON-encoded examples. * Added tool validation checks of JSON-encoded examples.
* Added a recommendation to ease extracting and validating examples. * Added a recommendation to ease extracting and validating examples.
* Updated many examples to be aligned with the consistent * Updated many examples to be aligned with the consistent
indentation recommendation (internal consistency). indentation recommendation (internal consistency).
* Updated the IANA considerations to encourage registration requests * Updated the IANA considerations to encourage registration requests
to indicate whether a module is maintained by IANA or not. to indicate whether or not a module is maintained by IANA.
* Added guidelines for IANA-maintained modules. * Added guidelines for IANA-maintained modules.
* Added guidelines about the use of "YANG module" and "YANG data * Added guidelines about the use of the terms "YANG module" and
model". "YANG data model".
* Elaborated the guidance for the use of values reserved for * Elaborated the guidance for the use of values reserved for
documentation in examples. documentation in examples.
* Recommended the use of "example:" for URI examples. * Recommended the use of "example:" for URI examples.
* Added a new section "Defining Standard Tags" (Section 4.28) to * Added a new section "Defining Standard Tags" (Section 4.28) to
echo the guidance in [RFC8819]. echo the guidance in [RFC8819].
* Recommended against the use of "case + when" construct in some * Recommended against the use of "case + when" construct in some
cases. cases.
* Added a discussion about the prefix pattern to use for example * Added a discussion about the prefix pattern to use for example
modules. modules.
* Updated the NMDA guidance in the narrative text to highlight * Updated the NMDA guidance in the narrative text to highlight
modules that are not NMDA-compliant. modules that are not compliant with NMDA.
* Added a new section about YANG module classification. * Added a new section about the classification of YANG modules.
* Fixed an inconsistency in Section 4.6.2 where the example mentions * Fixed an inconsistency in Section 4.6.2 where the example mentions
identities, but uses them without their prefix as per identities but uses them without their prefix as per
Section 4.6.4. Section 4.6.4.
* Fixed an inconsistency in Section 4.6.4 which fails to use * Fixed an inconsistency in Section 4.6.4 that failed to use
"derived-from-or-self()" mentioned back in Section 4.6.2. "derived-from-or-self()" mentioned back in Section 4.6.2.
* Added a new section for modeling abstract data structures. * Added a new section for modeling abstract data structures.
* Added a discussion about "must + error-message" constructs for * Added a discussion about "must + error-message" constructs for
state data. state data.
* Added text about summary of changes in revision statements. * Added text about summary of changes in revision statements.
* Added a template for IANA-maintained modules. * Added a template for IANA-maintained modules.
* Updated the wiki URLs to use the new structure instead of the old * Updated the wiki URLs to use the new structure.
trac.
* Added anydata to the list of statements with mandatory description * Added anydata to the list of statements with mandatory
(Section 4.14). description(s) (Section 4.14).
* Fixed an error (invalid statements) in Section 4.24. * Fixed an error (invalid statements) in Section 4.24.
* Soften generic I-Ds authorship guidance. * Softened generic I-D authorship guidance.
2. Terminology & Notation Conventions 2. Terminology and Notation Conventions
Some of the templates defined in the document use "--" to easily Some of the templates defined in the document use "--" to easily
identify specific instructions to the authors. Text prefixed with identify specific instructions to the authors. Text prefixed with
"--" must not be copied as such when using a template. Note that for "--" must not be copied as such when using a template. Note that for
YANG templates, "//" is used to convey such instructions. YANG templates, "//" is used to convey such instructions.
RFC IIII is used to refer to an RFC that defines an initial version RFC IIII is used to refer to an RFC that defines an initial version
of an IANA-maintained module. of an IANA-maintained module.
The following terms are used throughout this document: The following terms are used throughout this document:
IANA-maintained module: A YANG module that is maintained by IANA and IANA-maintained module: A YANG module that is maintained by IANA and
has an IANA registry associated with it (e.g., "iana-tunnel-type" has an IANA registry associated with it (e.g., "iana-tunnel-type"
[RFC8675] or "iana-pseudowire-types" [RFC9291]). [RFC8675] or "iana-pseudowire-types" [RFC9291]).
Once an IANA-maintained module is initialized, new values are not Once an IANA-maintained module is initialized, new values are not
directly added to the module. These values are instead added to directly added to the module. These values are instead added to
the companion registry. the companion registry.
IETF module: A YANG module that is published by the IETF and that is IETF module: A YANG module that is published as an RFC from the IETF
not maintained by IANA. Stream and that is not maintained by IANA.
published: A stable release of a module or submodule. For example, published: A stable release of a module or submodule. For example,
the "Request for Comments" described in Section 2.1 of [RFC2026] the "Request for Comments" described in Section 2.1 of [RFC2026]
is considered a stable publication. is considered a stable publication.
unpublished: An unstable release of a module or submodule. For unpublished: An unstable release of a module or submodule. For
example the "Internet-Draft" described in Section 2.2 of [RFC2026] example, the "Internet-Draft" described in Section 2.2 of
is considered an unstable publication that is a work in progress, [RFC2026] is considered an unstable publication that is a work in
subject to change at any time. progress and is subject to change at any time.
YANG fragment: A set of YANG statements that are not intended to YANG fragment: A set of YANG statements that is not intended to
represent a complete YANG module or submodule. These statements represent a complete YANG module or submodule. These statements
are not intended for actual use, except to provide an example of are not intended for actual use, except to provide an example of
YANG statement usage. The invalid syntax "..." is sometimes used YANG statement usage. The invalid syntax "..." is sometimes used
to indicate that additional YANG statements would be present in a to indicate that additional YANG statements would be present in a
real YANG module. real YANG module.
YANG tree diagram: A diagram representing the contents of a YANG YANG tree diagram: A diagram representing the contents of a YANG
module, as defined in [RFC8340]. It is also called a "tree module, as defined in [RFC8340]. It is also called a "tree
diagram". diagram".
skipping to change at page 9, line 39 skipping to change at line 392
* namespace * namespace
* submodule * submodule
* version * version
* YANG * YANG
* YIN * YIN
Note that the term 'module' may be used as a generic term for a YANG Note that the term "module" may be used as a generic term for a YANG
module or submodule. When describing properties that are specific to module or submodule. When describing properties that are specific to
submodules, the term 'submodule' is used instead. submodules, the term "submodule" is used instead.
2.3. Network Management Datastore Architecture (NMDA) Terms 2.3. Network Management Datastore Architecture (NMDA) Terms
The following terms are defined in [RFC8342] and are not redefined The following terms are defined in [RFC8342] and are not redefined
here: here:
* configuration * configuration
* conventional configuration datastore * conventional configuration datastore
* datastore * datastore
* operational state * operational state
* operational state datastore * operational state datastore
2.4. Requirements Notation 2.4. Requirements Notation
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.
2.5. YANG Data Model vs. YANG Module 2.5. YANG Data Model versus YANG Module
Both [RFC6020] and [RFC7950] make a distinction between the following Both [RFC6020] and [RFC7950] make a distinction between the following
concepts: concepts:
data model: Describes how data is represented and accessed. data model: Describes how data is represented and accessed.
YANG structures data models into modules for ease of use YANG structures data models into modules for ease of use
[RFC8309]. [RFC8309].
module: Defines hierarchies of schema nodes to make a self-contained module: Defines hierarchies of schema nodes to make a self-contained
and compilable block of YANG definitions and inclusions. and compilable block of YANG definitions and inclusions.
A YANG module is typically a single ".yang" file, starting with a A YANG module is typically a single ".yang" file, starting with a
"module" statement. "module" statement.
A YANG module may include any number of submodules that are stored A YANG module may include any number of submodules that are stored
in separate ".yang" files starting with a "submodule" statement. in separate ".yang" files starting with a "submodule" statement.
Regardless of the presence of submodules, the module and its Regardless of the presence of submodules, the module and its
submodules are externally viewed as a single YANG module. submodules are externally viewed as a single YANG module.
A YANG data model can consist (1) of a single YANG module (e.g., A YANG data model can consist of:
[RFC9129]) or (2) multiple YANG modules (e.g., [RFC7407]).
1. a single YANG module (e.g., [RFC9129]) or
2. multiple YANG modules (e.g., [RFC7407]).
Note that the term "YANG model" is sometimes used as an abbreviation Note that the term "YANG model" is sometimes used as an abbreviation
of YANG data model. However, that term should be avoided in favor of of "YANG data model". However, that term should be avoided in favor
YANG data model. Likewise, "YANG data module" has no meaning and of "YANG data model". Likewise, "YANG data module" has no meaning
must be avoided. and must be avoided.
Even if a YANG data model is structured as a single YANG module, YANG Even if a YANG data model is structured as a single YANG module, the
data model term should be used in the title, abstract, and in the term "YANG data model" should be used in the title, abstract, and in
body of the document where the overall design is described. "YANG the body of the document where the overall design is described.
module" should be used when a specific "*.yang" file is referenced. "YANG module" should be used when a specific "*.yang" file is
Likewise, "YANG module" should be used when using terms related to referenced. Likewise, "YANG module" should be used when using terms
YANG module specifications (e.g., augmentation or deviation). related to YANG module specifications (e.g., augmentation or
However, when extending the concepts embodied in a YANG module, deviation). However, when extending the concepts embodied in a YANG
authors should refer to those as an extension to the "YANG data module, authors should refer to those as an extension to the "YANG
model". data model".
3. General Documentation Guidelines 3. General Documentation Guidelines
YANG modules under review are likely to be contained in Internet- YANG modules under review are likely to be contained in Internet-
Drafts (I-Ds). Guidelines for I-D authors can be found at Drafts (I-Ds). Guidelines for authoring an I-D can be found at
[ID-Guidelines]. These guidelines are not repeated here. [ID-Guidelines]. These guidelines are not repeated here.
The following sections MUST be present in an I-D or RFC containing a The following sections MUST be present in an I-D or RFC containing a
YANG module: YANG module:
* Narrative sections (Section 3.5) * Narrative sections (Section 3.5)
* Definitions section (Section 3.6) * A Definitions section (Section 3.6)
Additional YANG-specific considerations MUST be included for the Additional YANG-specific considerations MUST be included for the
following sections: following sections:
* Security Considerations section (Section 3.7) * Security Considerations (Section 3.7)
* IANA Considerations section (Section 3.8) * IANA Considerations (Section 3.8)
* References section (Section 3.9) * References (Section 3.9)
There are three usage scenarios for YANG that can appear in an I-D or There are three usage scenarios for YANG that can appear in an I-D or
RFC: RFC:
* normative module or submodule * normative module or submodule
* example module or submodule * example module or submodule
* example YANG fragment not part of any module or submodule * example YANG fragment that is not part of any module or submodule
The guidelines in this document refer mainly to a normative module or The guidelines in this document refer mainly to a normative module or
submodule but may be applicable to example modules and YANG fragments submodule, but they may be applicable to example modules and YANG
as well. fragments as well.
3.1. Module Copyright 3.1. Module Copyright
The module "description" statement MUST contain a reference to the The module "description" statement MUST contain a reference to the
latest approved IETF Trust Copyright statement, which is available latest approved IETF Trust Copyright statement, which is available
online at: at: <https://trustee.ietf.org/license-info/>.
<https://trustee.ietf.org/license-info/>
3.2. Code Components 3.2. Code Components
Each normative YANG module or submodule contained within an I-D or Each normative YANG module or submodule contained within an I-D or
RFC is considered to be a code component. The strings "<CODE RFC is considered to be a code component. The strings "<CODE
BEGINS>" and "<CODE ENDS>" MUST be used to identify each code BEGINS>" and "<CODE ENDS>" MUST be used to identify each code
component. component.
The "<CODE BEGINS>" tag MUST be followed by a string identifying the The "<CODE BEGINS>" tag MUST be followed by a string identifying the
file name specified in Section 5.2 of [RFC7950]. The name string file name specified in Section 5.2 of [RFC7950]. The name string
form that includes the revision date SHOULD be used. The revision form that includes the revision date SHOULD be used. The revision
date MUST match the date used in the most recent revision of the date MUST match the date used in the most recent revision of the
module. module.
The following example is for the "2016-03-20" revision of the "ietf- The following example is for the "2016-03-20" revision of the "ietf-
foo" module: foo" module:
<CODE BEGINS> file "ietf-foo@2016-03-20.yang" <CODE BEGINS>
file "ietf-foo@2016-03-20.yang"
module ietf-foo { module ietf-foo {
namespace "urn:ietf:params:xml:ns:yang:ietf-foo"; namespace "urn:ietf:params:xml:ns:yang:ietf-foo";
prefix "foo"; prefix "foo";
organization "..."; organization "...";
contact "..."; contact "...";
description "..."; description "...";
revision 2016-03-20 { revision 2016-03-20 {
description "Latest revision"; description "Latest revision";
reference "RFC FFFF: Foo Protocol"; reference "RFC FFFF: Foo Protocol";
skipping to change at page 13, line 41 skipping to change at line 583
If the module or modules defined by the specification imports If the module or modules defined by the specification imports
definitions from other modules (except for those defined in [RFC7950] definitions from other modules (except for those defined in [RFC7950]
or [RFC6991]) or are always implemented in conjunction with other or [RFC6991]) or are always implemented in conjunction with other
modules, then those facts MUST be noted in the overview section; any modules, then those facts MUST be noted in the overview section; any
special interpretations of definitions in other modules MUST be noted special interpretations of definitions in other modules MUST be noted
as well. Refer to Section 2.3 of [RFC8349] for an example of this as well. Refer to Section 2.3 of [RFC8349] for an example of this
overview section. overview section.
If the document contains major Network Management Datastore If the document contains major Network Management Datastore
Architecture (NMDA) exceptions or include a temporary non-NMDA module Architecture (NMDA) exceptions or includes a temporary non-NMDA
[RFC8342], then the Introduction section SHOULD mention this fact module [RFC8342], then the Introduction section SHOULD mention this
with the reasoning that motivated that design. Refer to Section 4.23 fact with the reasoning that motivated that design. Refer to
for more NMDA-related guidance. Specifically, Section 4.23.2 Section 4.23 for more NMDA-related guidance. Specifically,
includes a recommendation for designers to describe and justify any Section 4.23.2 includes a recommendation for designers to describe
NMDA exceptions in detail as part of the module itself. and justify any NMDA exceptions in detail as part of the module
itself.
Consistent indentation SHOULD be used for all examples, including Consistent indentation SHOULD be used for all examples, including
YANG fragments and protocol message instance data. If line wrapping YANG fragments and protocol message instance data. If line wrapping
is done for formatting purposes, then this SHOULD be indicated per is used for formatting purposes, then this SHOULD be indicated per
the guidance in [RFC8792], as shown in the following example: the guidance in [RFC8792], as shown in the following example:
=============== NOTE: '\' line wrapping per RFC 8792 ================ =============== NOTE: '\' line wrapping per RFC 8792 ================
<myleaf xmlns="tag:example.com,2017:example-two">this is a long \ <myleaf xmlns="tag:example.com,2017:example-two">this is a long \
value so the line needs to wrap to stay within 72 characters</myleaf> value so the line needs to wrap to stay within 72 characters</myleaf>
Built-in YANG features (e.g., breaking line, "+") SHOULD be used to Built-in YANG features (e.g., breaking line, "+") SHOULD be used to
fit a module into the line limits. Exceptionally, RFC8792-folding of fit a module into the line limits. Exceptionally, YANG modules MAY
YANG modules MAY be used if and only if built-in YANG features are be folded as described in RFC 8792 if and only if built-in YANG
not sufficient. A similar approach (e.g., use "--tree-line-length features are not sufficient. A similar approach (e.g., using "--
69" or split a tree into subtrees) SHOULD be followed for tree tree-line-length 69" or splitting a tree into subtrees) SHOULD be
diagrams. followed for tree diagrams.
3.5.1. YANG Module Classification 3.5.1. YANG Module Classification
The narrative section SHOULD include a mention about the The narrative section SHOULD include a mention of the classification
classification of a given model. Such a mention is meant to ease of a given model. Such a mention is meant to ease positioning the
positioning the module in the overall operational ecosystem. module in the overall operational ecosystem. Specifically, the
Specifically, the following types from [RFC8309] and [RFC8969] can be following types from [RFC8309] and [RFC8969] can be used:
used:
Service Model: Describes a service and the parameters of the service Service Model: Describes a service and the parameters of the service
in a portable way that can be used uniformly and independent of in a portable way that can be used uniformly and independent of
the equipment and operating environment. the equipment and operating environment.
Examples of service models are the L3VPN Service Model (L3SM) Examples of service models are the L3VPN Service Model (L3SM)
[RFC8299] and the L2VPN Service Model (L2SM) [RFC8466]. [RFC8299] and the L2VPN Service Model (L2SM) [RFC8466].
Network Model: Describes a network-level abstraction (or a subset of Network Model: Describes a network-level abstraction (or a subset of
aspects of a network infrastructure), including devices and their aspects of a network infrastructure), including devices and their
subsystems, and relevant protocols operating at the link and subsystems, and relevant protocols operating at the link and
network layers across multiple devices. This model corresponds to network layers across multiple devices. This model corresponds to
the network configuration model discussed in [RFC8309]. the network configuration model discussed in [RFC8309].
It can be used by a network operator to allocate resources (e.g., This model can be used by a network operator to allocate resources
tunnel resource, topology resource) for the service or schedule (e.g., a tunnel resource or a topology resource) for the service
resources to meet the service requirements defined in a service or to schedule resources to meet the service requirements defined
model. in a service model.
Examples of network models are the L3VPN Network Model (L3NM) Examples of network models are the L3VPN Network Model (L3NM)
[RFC9182] or the L2VPN Network Model (L2NM) [RFC9291]. [RFC9182] or the L2VPN Network Model (L2NM) [RFC9291].
Device Model: Refers to the Network Element YANG data model Device Model: Refers to the Network Element YANG data model
described in [RFC8199] or the device configuration model discussed described in [RFC8199] or the device configuration model discussed
in [RFC8309]. in [RFC8309].
Device models are also used to model a function embedded in a Device models are also used to model a function embedded in a
device (e.g., Access Control Lists (ACLs) [RFC8519]). device (e.g., Access Control Lists (ACLs) [RFC8519]).
A comprehensive list of device models is provided in Appendix 4.2 A comprehensive list of device models is provided in
of [RFC8969]. Appendix A.4.2 of [RFC8969].
3.6. Definitions Section 3.6. Definitions Section
This section contains the module(s) defined by the specification. This section contains the module(s) defined by the specification.
These modules SHOULD be written using the YANG 1.1 [RFC7950] syntax. These modules SHOULD be written using the YANG 1.1 [RFC7950] syntax.
YANG 1.0 [RFC6020] syntax MAY be used if no YANG 1.1 constructs or YANG 1.0 [RFC6020] syntax MAY be used if no YANG 1.1 constructs or
semantics are needed in the module. If any of the imported YANG semantics are needed in the module. If any of the imported YANG
modules are written using YANG 1.1, then the module MUST be written modules are written using YANG 1.1, then the module MUST be written
using YANG 1.1. using YANG 1.1.
A YIN syntax version (Section 13 of [RFC7950]) of the module MAY also A YANG Independent Notation (YIN) syntax version (Section 13 of
be present in the document. There MAY also be other types of modules [RFC7950]) of the module MAY also be present in the document. There
present in the document, such as Structure of Management Information MAY also be other types of modules present in the document, such as
Version 2 (SMIv2), which are not affected by these guidelines. Structure of Management Information Version 2 (SMIv2), which are not
affected by these guidelines.
Note that if the module itself is considered normative and not an Note that if the module itself is considered normative and not an
example module or example YANG fragment, then all YANG statements example module or example YANG fragment, then all YANG statements
within a YANG module are considered normative. The use of keywords within a YANG module are considered normative. The use of keywords
defined in [RFC2119] and [RFC8174] apply to YANG "description" defined in [RFC2119] and [RFC8174] apply to YANG "description"
statements in normative modules exactly as they would in any other statements in normative modules exactly as they would in any other
normative section. normative section.
Example YANG modules and example YANG fragments MUST NOT contain any Example YANG modules and example YANG fragments MUST NOT contain any
normative text, including any all-uppercase reserved words from normative text, including any all-uppercase reserved words from
skipping to change at page 16, line 27 skipping to change at line 715
the sensitivity/privacy concerns MUST be explained. the sensitivity/privacy concerns MUST be explained.
Documents that exclusively define modules that follow the extension Documents that exclusively define modules that follow the extension
in [RFC8791] are not required to include the security template in in [RFC8791] are not required to include the security template in
Section 3.7.1. Likewise, following the template is not required for Section 3.7.1. Likewise, following the template is not required for
modules that define YANG extensions such as [RFC7952]. modules that define YANG extensions such as [RFC7952].
3.7.1. Security Considerations Section Template 3.7.1. Security Considerations Section Template
<CODE BEGINS> <CODE BEGINS>
X. Security Considerations X. Security Considerations
This section is modeled after the template described in Section 3.7 This section is modeled after the template described in Section 3.7
of [RFCAAAA]. of [RFC9907].
The "<module-name>" YANG module defines a data model that is The "<module-name>" YANG module defines a data model that is
designed to be accessed via YANG-based management protocols, such as designed to be accessed via YANG-based management protocols, such as
NETCONF [RFC6241] and RESTCONF [RFC8040]. These YANG-based management NETCONF [RFC6241] and RESTCONF [RFC8040]. These YANG-based
protocols (1) have to use a secure transport layer management protocols (1) have to use a secure transport layer
(e.g., SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) have (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) have
to use mutual authentication. to use mutual authentication.
The Network Configuration Access Control Model (NACM) [RFC8341] The Network Configuration Access Control Model (NACM) [RFC8341]
provides the means to restrict access for particular NETCONF or provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content. RESTCONF protocol operations and content.
-- Writable nodes section: -- Writable nodes section:
-- --
skipping to change at page 17, line 14 skipping to change at line 752
operations (e.g., edit-config) and delete operations to these data operations (e.g., edit-config) and delete operations to these data
nodes without proper protection or authentication can have a negative nodes without proper protection or authentication can have a negative
effect on network operations. The following subtrees and data nodes effect on network operations. The following subtrees and data nodes
have particular sensitivities/vulnerabilities: have particular sensitivities/vulnerabilities:
-- If the data model contains any particularly sensitive data nodes, -- If the data model contains any particularly sensitive data nodes,
-- e.g., ones that are protected by a "nacm:default-deny-write" -- e.g., ones that are protected by a "nacm:default-deny-write"
-- or a "nacm:default-deny-all" extensions statement, then those -- or a "nacm:default-deny-all" extensions statement, then those
-- subtrees and data nodes must be listed, with an explanation of the -- subtrees and data nodes must be listed, with an explanation of the
-- associated security risks with a focus on how they can be -- associated security risks with a focus on how they can be
-- disruptive if abused. Otherwise, state: -- disruptive if abused. Otherwise, state:
-- --
-- "There are no particularly sensitive writable data nodes." -- "There are no particularly sensitive writable data nodes."
-- Readable nodes section: -- Readable nodes section:
-- --
-- If the data model contains any readable data nodes (i.e., those -- If the data model contains any readable data nodes (i.e., those
-- that are "config false" nodes, but also all other nodes, because -- that are "config false" nodes, but also all other nodes, because
-- they can also be read via operations like get or get-config), then -- they can also be read via operations like get or get-config), then
-- include the following text: -- include the following text:
Some of the readable data nodes in this YANG module may be considered Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or important to control read access (e.g., via get, get-config, or
notification) to these data nodes. Specifically, the following notification) to these data nodes. Specifically, the following
subtrees and data nodes have particular sensitivities/ subtrees and data nodes have particular sensitivities/
vulnerabilities: vulnerabilities:
-- You must evaluate whether the data model contains any readable -- You must evaluate whether the data model contains any readable
-- data nodes (those are all the "config false" nodes, but also all -- data nodes (those are all the "config false" nodes, but also all
-- other nodes, because they can also be read via operations like get -- other nodes, because they can also be read via operations like get
-- or get-config) are particularly sensitive or vulnerable (e.g., -- or get-config) are particularly sensitive or vulnerable (e.g.,
-- if they might reveal customer information or violate personal -- if they might reveal customer information or violate personal
-- privacy laws). Typically, particularly sensitive readable -- privacy laws). Typically, particularly sensitive readable
-- data nodes are ones that are protected by a -- data nodes are ones that are protected by a
-- "nacm:default-deny-read" or a "nacm:default-deny-all" extensions -- "nacm:default-deny-read" or a "nacm:default-deny-all" extensions
-- statement. -- statement.
-- --
-- Otherwise, state: -- Otherwise, state:
-- "There are no particularly sensitive readable data nodes." -- "There are no particularly sensitive readable data nodes."
-- RPC/action operations section: -- RPC/action operations section:
-- --
-- If the data model contains any RPC or action operations, then -- If the data model contains any RPC or action operations, then
skipping to change at page 18, line 26 skipping to change at line 811
-- Reusable groupings from other modules section: -- Reusable groupings from other modules section:
-- --
-- If the data model reuses groupings from other modules and -- If the data model reuses groupings from other modules and
-- the document that specifies these groupings also -- the document that specifies these groupings also
-- includes those as data nodes, then add this text to remind -- includes those as data nodes, then add this text to remind
-- the specific sensitivity or vulnerability of reused nodes. -- the specific sensitivity or vulnerability of reused nodes.
This YANG module uses groupings from other YANG modules that This YANG module uses groupings from other YANG modules that
define nodes that may be considered sensitive or vulnerable define nodes that may be considered sensitive or vulnerable
in network environments. Refer to the Security Considerations in network environments. Refer to the Security Considerations
of <RFC-insert-numbers> for information as to which nodes may of <RFC-insert-numbers> for information as to which nodes may
be considered sensitive or vulnerable in network environments. be considered sensitive or vulnerable in network environments.
-- No data nodes section: -- No data nodes section:
-- --
-- If the data model does not define any data nodes (i.e., none -- If the data model does not define any data nodes (i.e., none
-- of the above sections or readable/writable data nodes or RPCs -- of the above sections or readable/writable data nodes or RPCs
-- have been included), then add the following text: -- have been included), then add the following text:
The YANG module defines a set of identities, types, and The YANG module defines a set of identities, types, and
groupings. These nodes are intended to be reused by other YANG groupings. These nodes are intended to be reused by other YANG
modules. The module by itself does not expose any data nodes that modules. The module by itself does not expose any data nodes that
are writable, data nodes that contain read-only state, or RPCs. are writable, data nodes that contain read-only state, or RPCs.
As such, there are no additional security issues related to As such, there are no additional security issues related to
the YANG module that need to be considered. the YANG module that need to be considered.
Modules that use the groupings that are defined in this document Modules that use the groupings that are defined in this document
should identify the corresponding security considerations. For should identify the corresponding security considerations. For
example, reusing some of these groupings will expose privacy-related example, reusing some of these groupings will expose privacy-related
information (e.g., 'node-example'). information (e.g., 'node-example').
<CODE ENDS>
Note: [RFC8341] (or a future RFC that replaces it) MUST be listed as <CODE ENDS>
a normative reference.
By default, [RFC4252], [RFC6241], [RFC8040], [RFC8446], [RFC9000], | Note: [RFC8341] (or a future RFC that replaces it) MUST be
and RFC AAAA (or future RFCs that replace any of them) are listed | listed as a normative reference.
as informative references unless normatively cited in other |
sections of the document that specifies the YANG module. | By default, [RFC4252], [RFC6241], [RFC8040], [RFC8446],
| [RFC9000], and RFC 9907 (or future RFCs that replace any of
| them) are listed as informative references unless normatively
| cited in other sections of the document that specifies the YANG
| module.
3.8. IANA Considerations Section 3.8. IANA Considerations Section
Each normative YANG module MUST be registered in both the "IETF XML Each normative YANG module MUST be registered in both the "IETF XML
Registry" group [RFC3688] [IANA-XML] and the "YANG Module Names" Registry" group [RFC3688] [IANA-XML] and the "YANG Module Names"
registry [RFC6020] [IANA-MOD-NAMES]. The registration request in the registry [RFC6020] [IANA-MOD-NAMES]. The registration request in the
"YANG Module Names" registry should indicate whether the module is "YANG Module Names" registry should indicate whether or not the
IANA-maintained or not. This applies to new modules and updated module is IANA-maintained. This applies to new modules and updated
modules. An example of an update registration for the "ietf- modules. An example of an update registration for the "ietf-
template" module can be found in Section 5. template" module can be found in Section 5.
Additional IANA considerations applicable to IANA-maintained modules Additional IANA considerations applicable to IANA-maintained modules
(including instructions to maintain them) are provided in (including instructions to maintain them) are provided in
Section 4.30.3. Section 4.30.3.
3.8.1. Documents That Create a New Namespace 3.8.1. Documents That Create a New Namespace
If an I-D defines a new namespace that is to be administered by the If an I-D defines a new namespace that is to be administered by the
IANA, then the document MUST include an IANA Considerations section IANA, then the document MUST include an IANA Considerations section
that specifies how the namespace is to be administered. that specifies how the namespace is to be administered.
Specifically, if any YANG module namespace statement value contained Specifically, if any YANG module namespace statement value contained
in the document is not already registered with IANA, then a new entry in the document is not already registered with IANA, then a new entry
in the "ns" registry within the "IETF XML Registry" group MUST be in the "ns" registry within the "IETF XML Registry" registry group
requested from the IANA. MUST be requested from the IANA.
A registration template for new YANG modules is provided in A registration template for new YANG modules is provided in
Section 3.8.3.1. Section 3.8.3.1.
3.8.2. Documents That Extend an Existing Namespace 3.8.2. Documents That Extend an Existing Namespace
It is possible to extend an existing namespace using a YANG submodule It is possible to extend an existing namespace using a YANG submodule
that belongs to an existing module already administered by IANA. In that belongs to an existing module already administered by IANA. In
this case, the document containing the main module MUST be updated to this case, the document containing the main module MUST be updated to
use the latest revision of the submodule. use the latest revision of the submodule.
3.8.3. Registration Templates 3.8.3. Registration Templates
3.8.3.1. IANA Template for Documents Defining New YANG Modules 3.8.3.1. IANA Template for Documents Defining New YANG Modules
A registration template for a new module is provided below: A registration template for a new module is provided below:
IANA is requested to register the following URI in the "ns" IANA is requested to register the following URI in the "ns"
registry within the "IETF XML Registry" group [RFC3688]: registry within the "IETF XML Registry" group [RFC3688]:
URI: URI:
Registrant Contact: The IESG. Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
IANA is requested to register the following YANG module in the "YANG IANA is requested to register the following YANG module in the "YANG
Module Names" registry [RFC6020] within the "YANG Parameters" Module Names" registry [RFC6020] within the "YANG Parameters"
registry group. registry group.
Name: Name:
Maintained by IANA? Y/N Maintained by IANA? Y/N
Namespace: Namespace:
Prefix: Prefix:
Reference: Reference:
3.8.3.2. IANA Template for Revising YANG Modules 3.8.3.2. IANA Template for Revising YANG Modules
A registration template for a revised module is provided below: A registration template for a revised module is provided below:
IANA is requested to update the following registration in the "ns" IANA is requested to update the following registration in the "ns"
registry within the "IETF XML Registry" group [RFC3688] to registry within the "IETF XML Registry" group [RFC3688] to
reference this document: reference this document:
URI: URI:
Registrant Contact: The IESG. Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
IANA is requested to register the following YANG module in the "YANG IANA is requested to register the following YANG module in the "YANG
Module Names" registry [RFC6020] within the "YANG Parameters" Module Names" registry [RFC6020] within the "YANG Parameters"
registry group. registry group.
Name: Name:
Maintained by IANA? Y/N Maintained by IANA? Y/N
Namespace: Namespace:
Prefix: Prefix:
Reference: Reference:
3.9. References Sections 3.9. References Sections
For every import or include statement that appears in a module For every import or include statement that appears in a module
contained in the specification that identifies a module in a separate contained in the specification that identifies a module in a separate
document, a corresponding normative reference to that document MUST document, a corresponding normative reference to that document MUST
appear in the Normative References section. The reference MUST appear in the Normative References section. The reference MUST
correspond to the specific module version actually used within the correspond to the specific module version actually used within the
specification. specification.
skipping to change at page 21, line 18 skipping to change at line 946
the Normative References section. The reference SHOULD correspond to the Normative References section. The reference SHOULD correspond to
the specific document version actually used within the specification. the specific document version actually used within the specification.
If the reference statement identifies an informative reference that If the reference statement identifies an informative reference that
identifies a separate document, a corresponding informative reference identifies a separate document, a corresponding informative reference
to that document MAY appear in the Informative References section. to that document MAY appear in the Informative References section.
3.10. Validation Tools 3.10. Validation Tools
All modules need to be validated before submission in an I-D. The All modules need to be validated before submission in an I-D. The
'pyang' YANG compiler is freely available from GitHub: 'pyang' YANG compiler is freely available from GitHub:
<https://github.com/mbj4668/pyang>.
<https://github.com/mbj4668/pyang>
If the 'pyang' compiler is used to validate a normative module, then If the 'pyang' compiler is used to validate a normative module, then
the "--ietf" command-line option MUST be used to identify any IETF the "--ietf" command-line option MUST be used to identify any IETF
guideline issues. guideline issues.
If the 'pyang' compiler is used to validate an example module, then If the 'pyang' compiler is used to validate an example module, then
the "--ietf" command-line option MAY be used to identify any IETF the "--ietf" command-line option MAY be used to identify any IETF
guideline issues. guideline issues.
To ensure that a module fits into the line limits of an I-D, the To ensure that a module fits into the line limits of an I-D, the
command "pyang -f yang --keep-comments --yang-line-length 69" should command "pyang -f yang --keep-comments --yang-line-length 69" should
be used. be used.
The "yanglint" program is also freely available from GitHub. The "yanglint" program is also freely available from GitHub:
<https://github.com/CESNET/libyang>.
<https://github.com/CESNET/libyang>
This tool can be used to validate XPath statements within YANG This tool can be used to validate XPath statements within YANG
modules. modules.
To check that JSON-encoded examples [RFC7951] comply with the target To check that JSON-encoded examples [RFC7951] comply with the target
data models, programs such as "yangson" or "yanglint" should be used. data models, programs such as "yangson" or "yanglint" should be used.
Both programs are freely available from GitHub. Both programs are freely available from GitHub: <https://github.com/
CZ-NIC/yangson> and <https://github.com/CESNET/libyang>.
<https://github.com/CZ-NIC/yangson>
<https://github.com/CESNET/libyang>
3.11. Module Extraction Tools 3.11. Module Extraction Tools
A version of 'rfcstrip' that will extract YANG modules from an I-D or A version of 'rfcstrip' that will extract YANG modules from an I-D or
RFC is available. The 'rfcstrip' tool that supports YANG module RFC is freely available at: <https://github.com/mbj4668/rfcstrip>.
extraction is freely available at:
<https://github.com/mbj4668/rfcstrip>
This tool can be used to verify that the "<CODE BEGINS>" and "<CODE This tool can be used to verify that the "<CODE BEGINS>" and "<CODE
ENDS>" tags are used correctly and that the normative YANG modules ENDS>" tags are used correctly and that the normative YANG modules
can be extracted correctly. can be extracted correctly.
The 'xym' tool is freely available on GitHub and can be used to The 'xym' tool is freely available on GitHub and can be used to
extract YANG modules from a document. extract YANG modules from a document: <https://github.com/xym-tool/
xym>.
<https://github.com/xym-tool/xym>
3.12. Module Usage Examples 3.12. Module Usage Examples
Each specification that defines one or more modules SHOULD contain Each specification that defines one or more modules SHOULD contain
usage examples, either throughout the document or in an appendix. usage examples, either throughout the document or in an appendix.
This includes example instance document snippets in an appropriate This includes example instance document snippets in an appropriate
encoding (e.g., XML and/or JSON) to demonstrate the intended usage of encoding (e.g., XML and/or JSON) to demonstrate the intended usage of
the YANG module(s). Examples MUST be validated (Section 3.10). the YANG module(s). Examples MUST be validated (Section 3.10).
Refer to Section 3.10 for tools that validate YANG modules and Refer to Section 3.10 for tools that validate YANG modules and
examples. If IP addresses/prefixes are used, then a mix of either examples. If IP addresses/prefixes are used, then a mix of either
skipping to change at page 27, line 7 skipping to change at line 1205
+--------------+---------------+ +--------------+---------------+
| status | current | | status | current |
+--------------+---------------+ +--------------+---------------+
| yin-element | false | | yin-element | false |
+--------------+---------------+ +--------------+---------------+
Table 1: Statement Defaults Table 1: Statement Defaults
4.5. Conditional Statements 4.5. Conditional Statements
A module may be conceptually partitioned in several ways, using the A module may be conceptually partitioned in several ways using the
"if-feature" and/or "when" statements. "if-feature" and/or "when" statements.
Data model designers need to carefully consider all modularity Data model designers need to carefully consider all modularity
aspects, including the use of YANG conditional statements. aspects, including the use of YANG conditional statements.
If a data definition is optional, depending on server support for a If a data definition is optional, depending on server support for a
NETCONF or RESTCONF protocol capability, then a YANG "feature" NETCONF or RESTCONF protocol capability, then a YANG "feature"
statement SHOULD be defined. The defined "feature" statement SHOULD statement SHOULD be defined. The defined "feature" statement SHOULD
then be used in the conditional "if-feature" statement referencing then be used in the conditional "if-feature" statement referencing
the optional data definition. the optional data definition.
If any notification data, or any data definition, for a non- If any notification data, or any data definition, for a non-
configuration data node is not mandatory, then the server may or may configuration data node is not mandatory, then the server may or may
not be required to return an instance of this data node. If any not be required to return an instance of this data node. If any
conditional requirements exist for returning the data node in a conditional requirements exist for returning the data node in a
notification payload or retrieval request, they MUST be documented notification payload or retrieval request, they MUST be documented
somewhere. For example, a "when" or "if-feature" statement could somewhere. For example, a "when" or "if-feature" statement could
apply to the data node, or the conditional requirements could be apply to the data node or the conditional requirements could be
explained in a "description" statement within the data node or one of explained in a "description" statement within the data node or one of
its ancestors (if any). its ancestors (if any).
If any "if-feature" statements apply to a list node, then the same If any "if-feature" statements apply to a list node, then the same
"if-feature" statements MUST apply to any key leaf nodes for the "if-feature" statements MUST apply to any key leaf nodes for the
list. There MUST NOT be any "if-feature" statements applied to any list. There MUST NOT be any "if-feature" statements applied to any
key leafs that do not also apply to the parent list node. key leafs that do not also apply to the parent list node.
There SHOULD NOT be any "when" statements applied to a key leaf node. There SHOULD NOT be any "when" statements applied to a key leaf node.
It is possible that a "when" statement for an ancestor node of a key It is possible that a "when" statement for an ancestor node of a key
leaf will have the exact node-set result as the key leaf. In such a leaf will have the exact node-set result as the key leaf. In such a
case, the "when" statement for the key leaf is redundant and SHOULD case, the "when" statement for the key leaf is redundant and SHOULD
be avoided. be avoided.
Some modules use "case + when" construct but provide duplicated Some modules use a "case + when" construct but provide duplicated
information (e.g., the "when" statements are constraining a single information (e.g., the "when" statements are constraining a single
case in the choice as shown in the example below). Such constructs case in the choice as shown in the example below). Such constructs
with duplicated information SHOULD NOT be used. with duplicated information SHOULD NOT be used.
leaf type { leaf type {
type enumeration { type enumeration {
enum a; enum a;
enum b; enum b;
enum c; enum c;
} }
skipping to change at page 29, line 28 skipping to change at line 1296
} }
container type-c { container type-c {
when "../type = 'c'"; when "../type = 'c'";
leaf bar { leaf bar {
mandatory true; mandatory true;
type string; type string;
} }
} }
Note that the use of "case + when" is still useful in cases where Note that the use of "case + when" is still useful in cases where
complementary modelling constraints should be expressed. See the complementary modeling constraints should be expressed. See the
example provided below. example provided below:
leaf type { leaf type {
type enumeration { type enumeration {
enum a; enum a;
enum b; enum b;
enum c; enum c;
} }
} }
choice second-type { choice second-type {
mandatory true; mandatory true;
skipping to change at page 30, line 48 skipping to change at line 1342
} }
} }
} }
Section 8.1 of [RFC7950] includes provisions for defining constraints Section 8.1 of [RFC7950] includes provisions for defining constraints
on state data and specifies that a constraint must be true in a valid on state data and specifies that a constraint must be true in a valid
state data tree. However, Section 5.3 of [RFC8342] softens that state data tree. However, Section 5.3 of [RFC8342] softens that
behavior by allowing semantic constraints to be violated under some behavior by allowing semantic constraints to be violated under some
circumstances to help to detect anomalies. Relaxing validation circumstances to help to detect anomalies. Relaxing validation
constraints on state data is meant to reveal deviations of the constraints on state data is meant to reveal deviations of the
observed behavior vs. intended behavior of a managed entity and observed behavior versus intended behavior of a managed entity and
hopefully trigger corrective actions by a management system. From hopefully trigger corrective actions by a management system. From
that perspective, it is RECOMMENDED to avoid defining constraints on that perspective, it is RECOMMENDED to avoid defining constraints on
state data that would hinder the detection by a management system of state data that would hinder the detection by a management system of
abnormal behaviors of a managed entity. abnormal behaviors of a managed entity.
4.6. XPath Usage 4.6. XPath Usage
This section describes guidelines for using the XML Path Language This section describes guidelines for using the XML Path Language
(XPath) [W3C.REC-xpath] within YANG modules. (XPath) [W3C.REC-xpath] within YANG modules.
skipping to change at page 34, line 21 skipping to change at line 1507
"boolean", or "number" functions), instead of implicit XPath data "boolean", or "number" functions), instead of implicit XPath data
type conversions. type conversions.
XPath expressions that contain a literal value representing a YANG XPath expressions that contain a literal value representing a YANG
identity SHOULD always include the declared prefix of the module identity SHOULD always include the declared prefix of the module
where the identity is defined. where the identity is defined.
XPath expressions for "when" statements SHOULD NOT reference the XPath expressions for "when" statements SHOULD NOT reference the
context node or any descendant nodes of the context node. They MAY context node or any descendant nodes of the context node. They MAY
reference descendant nodes if the "when" statement is contained reference descendant nodes if the "when" statement is contained
within an "augment" statement, and the referenced nodes are not within an "augment" statement and the referenced nodes are not
defined within the "augment" statement. defined within the "augment" statement.
Example: Example:
augment "/rt:active-route/rt:input/rt:destination-address" { augment "/rt:active-route/rt:input/rt:destination-address" {
when "derived-from-or-self(rt:address-family, " when "derived-from-or-self(rt:address-family, "
+ "'v4ur:ipv4-unicast')" { + "'v4ur:ipv4-unicast')" {
description description
"This augment is valid only for IPv4 unicast."; "This augment is valid only for IPv4 unicast.";
} }
skipping to change at page 36, line 16 skipping to change at line 1595
accepted in addition to the "one" and "three" enum values. accepted in addition to the "one" and "three" enum values.
4.7. YANG Definition Lifecycle Management 4.7. YANG Definition Lifecycle Management
The YANG status statement MUST be present within a definition if its The YANG status statement MUST be present within a definition if its
value is "deprecated" or "obsolete". The status SHOULD NOT be value is "deprecated" or "obsolete". The status SHOULD NOT be
changed from "current" directly to "obsolete". An object SHOULD be changed from "current" directly to "obsolete". An object SHOULD be
available for at least one year after the publication date with a available for at least one year after the publication date with a
"deprecated" status before it is changed to "obsolete". "deprecated" status before it is changed to "obsolete".
The module or submodule name MUST NOT be changed, once the document The module or submodule name MUST NOT be changed once the document
containing the module or submodule is published. containing the module or submodule is published.
The module namespace URI value MUST NOT be changed, once the document The module namespace URI value MUST NOT be changed once the document
containing the module is published. containing the module is published.
The revision date substatement within the import statement SHOULD be The revision date substatement within the import statement SHOULD be
present if any groupings are used from the external module. present if any groupings are used from the external module.
The revision date substatement within the include statement SHOULD be The revision date substatement within the include statement SHOULD be
present if any groupings are used from the external submodule. present if any groupings are used from the external submodule.
If an import statement is for a module from a stable source (e.g., an If an import statement is for a module from a stable source (e.g., an
RFC for an IETF module), then a reference-stmt SHOULD be present RFC for an IETF module), then a reference-stmt SHOULD be present
skipping to change at page 37, line 13 skipping to change at line 1640
} }
4.8. Module Header, Meta, and Revision Statements 4.8. Module Header, Meta, and Revision Statements
For published modules, the namespace MUST be a globally unique URI, For published modules, the namespace MUST be a globally unique URI,
as defined in [RFC3986]. This value is usually assigned by the IANA. as defined in [RFC3986]. This value is usually assigned by the IANA.
The "organization" statement MUST be present. If the module is The "organization" statement MUST be present. If the module is
contained in a document intended for IETF Standards Track status, contained in a document intended for IETF Standards Track status,
then the organization SHOULD be the IETF working group (WG) chartered then the organization SHOULD be the IETF working group (WG) chartered
to write the document. Exceptions include (but not limited): example to write the document. Exceptions include (but are not limited to):
modules, IANA-maintained modules, or modules contained in AD- example modules, IANA-maintained modules, or modules contained in AD-
sponsored documents. For other standards organizations, a similar sponsored documents. For other standards organizations, a similar
approach is also suggested. approach is also suggested.
The "contact" statement MUST be present. If the module is contained The "contact" statement MUST be present. If the module is contained
in a document intended for Standards Track status, then the WG web in a document intended for Standards Track status, then the WG web
and mailing information SHOULD be present, and the main document and mailing information SHOULD be present, and the main document
author or editor contact information SHOULD be present. If author or editor contact information SHOULD be present. If
additional authors or editors exist, their contact information MAY be additional authors or editors exist, their contact information MAY be
present. There is no need to include the contact information for WG present. There is no need to include the contact information for WG
Chairs. Chairs.
The "description" statement MUST be present. For modules published The "description" statement MUST be present. For modules published
within IETF documents, the appropriate IETF Trust Copyright text MUST within IETF documents, the appropriate IETF Trust Copyright text MUST
be present, as described in Section 3.1 and contain the following be present, as described in Section 3.1, and MUST contain the
statement: following statement:
All revisions of IETF and IANA published modules can be found at | All revisions of IETF and IANA published modules can be found at
the "YANG Parameters" registry group: | the "YANG Parameters" registry group:
https://www.iana.org/assignments/yang-parameters. | <https://www.iana.org/assignments/yang-parameters>.
If the module relies on information contained in other documents, If the module relies on information contained in other documents,
which are not the same documents implied by the import statements which are not the same documents implied by the import statements
present in the module, then these documents MUST be identified in the present in the module, then these documents MUST be identified in the
reference statement. reference statement.
A "revision" statement MUST be present for each published version of A "revision" statement MUST be present for each published version of
the module. The "revision" statement MUST have a "reference" the module. The "revision" statement MUST have a "reference"
substatement. It MUST identify the published document that contains substatement. It MUST identify the published document that contains
the module. Modules are often extracted from their original the module. Modules are often extracted from their original
skipping to change at page 39, line 25 skipping to change at line 1747
- yang:centiseconds32 - yang:centiseconds32
- yang:milliseconds32 - yang:milliseconds32
- yang:microseconds32 - yang:microseconds32
- yang:microseconds64 - yang:microseconds64
- yang:nanoseconds32 - yang:nanoseconds32
- yang:nanoseconds64 - yang:nanoseconds64
- yang:language-tag - yang:language-tag
The yang-identifier definition has been aligned with YANG 1.1. The yang-identifier definition has been aligned with YANG 1.1.
Several pattern statements have been improved."; Several pattern statements have been improved.";
reference reference
"RFC YYYY: Common YANG Data Types"; "RFC 6991: Common YANG Data Types";
} }
revision 2013-07-15 { revision 2013-07-15 {
description description
"This revision adds the following new data types: "This revision adds the following new data types:
- yang:yang-identifier - yang:yang-identifier
- yang:hex-string - yang:hex-string
- yang:uuid - yang:uuid
- yang:dotted-quad"; - yang:dotted-quad";
reference reference
skipping to change at page 40, line 44 skipping to change at line 1813
urn:ietf:params:xml:ns:yang:ietf-netconf-state urn:ietf:params:xml:ns:yang:ietf-netconf-state
urn:ietf:params:xml:ns:yang:ietf-netconf urn:ietf:params:xml:ns:yang:ietf-netconf
Note that a different URN prefix string SHOULD be used for modules Note that a different URN prefix string SHOULD be used for modules
that are not Standards Track. The string SHOULD be selected that are not Standards Track. The string SHOULD be selected
according to the guidelines in Section 5.3 of [RFC7950]. according to the guidelines in Section 5.3 of [RFC7950].
The following URIs exemplify what might be used by modules that are The following URIs exemplify what might be used by modules that are
not Standards Track. Note that the domain "example.com" SHOULD be not Standards Track. Note that the domain "example.com" SHOULD be
used by example modules in IETF I-Ds. These URIs are not intended to used by example modules in I-Ds from the IETF Stream. These URIs are
be dereferenced. They are used for module namespace identification not intended to be dereferenced. They are used for module namespace
only. identification only.
Example URIs using URLs per [RFC3986]: Example URIs using URLs per [RFC3986]:
https://example.com/ns/example-interfaces https://example.com/ns/example-interfaces
https://example.com/ns/example-system https://example.com/ns/example-system
Example URIs using tags per [RFC4151]: Example URIs using tags per [RFC4151]:
tag:example.com,2017:example-interfaces tag:example.com,2017:example-interfaces
skipping to change at page 47, line 20 skipping to change at line 2107
If an appropriate units identifier can be associated with the desired If an appropriate units identifier can be associated with the desired
semantics, then a units statement SHOULD be present. semantics, then a units statement SHOULD be present.
If an appropriate default value can be associated with the desired If an appropriate default value can be associated with the desired
semantics, then a default statement SHOULD be present. semantics, then a default statement SHOULD be present.
If a significant number of derived types are defined, and it is If a significant number of derived types are defined, and it is
anticipated that these data types will be reused by multiple modules, anticipated that these data types will be reused by multiple modules,
then these derived types SHOULD be contained in a separate module or then these derived types SHOULD be contained in a separate module or
submodule, to allow easier reuse without unnecessary coupling. submodule to allow easier reuse without unnecessary coupling.
The "description" statement MUST be present. The "description" statement MUST be present.
If the type definition semantics are defined in an external document If the type definition semantics are defined in an external document
(other than another YANG module indicated by an import statement), (other than another YANG module indicated by an import statement),
then the reference statement MUST be present. then the reference statement MUST be present.
4.13. Reusable Groupings 4.13. Reusable Groupings
A reusable grouping is a YANG grouping that can be imported by A reusable grouping is a YANG grouping that can be imported by
skipping to change at page 52, line 6 skipping to change at line 2328
description-stmt within a feature-stmt MUST specify any interactions description-stmt within a feature-stmt MUST specify any interactions
with other features. with other features.
The set of YANG features defined in a module should be considered The set of YANG features defined in a module should be considered
carefully. Very fine granular features increase interoperability carefully. Very fine granular features increase interoperability
complexity and should be avoided. A likely misuse of the feature complexity and should be avoided. A likely misuse of the feature
mechanism is the tagging of individual leafs (e.g., counters) with mechanism is the tagging of individual leafs (e.g., counters) with
separate features. separate features.
If there is a large set of objects associated with a YANG feature, If there is a large set of objects associated with a YANG feature,
then consider moving those objects to a separate module, instead of then consider moving those objects to a separate module instead of
using a YANG feature. Note that the set of features within a module using a YANG feature. Note that the set of features within a module
is easily discovered by the reader, but the set of related modules is easily discovered by the reader, but the set of related modules
within the entire YANG library is not as easy to identify. Module within the entire YANG library is not as easy to identify. Module
names with a common prefix can help readers identify the set of names with a common prefix can help readers identify the set of
related modules, but this assumes the reader will have discovered and related modules, but this assumes the reader will have discovered and
installed all the relevant modules. installed all the relevant modules.
Another consideration for deciding whether to create a new module or Another consideration for deciding whether to create a new module or
add a YANG feature is the stability of the module in question. It add a YANG feature is the stability of the module in question. It
may be desirable to have a stable base module that is not changed may be desirable to have a stable base module that is not changed
skipping to change at page 56, line 20 skipping to change at line 2518
result. Therefore, multiple deviation statements in the same module, result. Therefore, multiple deviation statements in the same module,
for the same target object, SHOULD NOT be used. for the same target object, SHOULD NOT be used.
The "max-elements" statement is intended to describe an architectural The "max-elements" statement is intended to describe an architectural
limit to the number of list entries. It is not intended to describe limit to the number of list entries. It is not intended to describe
platform limitations. It is better to use a "deviation" statement platform limitations. It is better to use a "deviation" statement
for the platforms that have a hard resource limit. for the platforms that have a hard resource limit.
Example documenting platform resource limits: Example documenting platform resource limits:
Wrong: (max-elements in the list itself) Wrong: (max-elements in the list itself)
container backups { container backups {
list backup { list backup {
... ...
max-elements 10; max-elements 10;
... ...
} }
} }
Correct: (max-elements in a deviation) Correct: (max-elements in a deviation)
deviation /bk:backups/bk:backup { deviation /bk:backups/bk:backup {
deviate add { deviate add {
max-elements 10; max-elements 10;
} }
} }
4.21. Extension Statements 4.21. Extension Statements
The YANG "extension" statement is used to specify external The YANG "extension" statement is used to specify external
skipping to change at page 61, line 44 skipping to change at line 2752
current modeling strategies. Both the NMDA and the non-NMDA current modeling strategies. Both the NMDA and the non-NMDA
modules SHOULD be published in the same document, with NMDA modules SHOULD be published in the same document, with NMDA
modules in the document main body and the non-NMDA modules in a modules in the document main body and the non-NMDA modules in a
non-normative appendix. The use of the non-NMDA module will non-normative appendix. The use of the non-NMDA module will
allow temporary bridging of the time period until NMDA allow temporary bridging of the time period until NMDA
implementations are available. implementations are available.
(b) For published models, the model should be republished with an (b) For published models, the model should be republished with an
NMDA-compatible structure, deprecating non-NMDA constructs. For NMDA-compatible structure, deprecating non-NMDA constructs. For
example, the "ietf-interfaces" model in [RFC7223] has been example, the "ietf-interfaces" model in [RFC7223] has been
restructured as an NMDA-compatible model in [RFC8343]. The restructured as an NMDA-compatible model in [RFC8343] (which
"/interfaces-state" hierarchy has been marked "status obsoletes [RFC7223]). The "/interfaces-state" hierarchy has
deprecated". Models that mark their "/foo-state" hierarchy with been marked "status deprecated". Models that mark their "/foo-
"status deprecated" will allow NMDA-capable implementations to state" hierarchy with "status deprecated" will allow NMDA-
avoid the cost of duplicating the state nodes, while enabling capable implementations to avoid the cost of duplicating the
non-NMDA-capable implementations to utilize them for access to state nodes, while enabling non-NMDA-capable implementations to
the operational values. utilize them for access to the operational values.
(c) For models that augment models that have not been structured (c) For models that augment models that have not been structured
with the NMDA, the modeler will have to consider the structure with the NMDA, the modeler will have to consider the structure
of the base model and the guidelines listed above. Where of the base model and the guidelines listed above. Where
possible, such models should move to new revisions of the base possible, such models should move to new revisions of the base
model that are NMDA compatible. When that is not possible, model that are NMDA compatible. When that is not possible,
augmenting "state" containers SHOULD be avoided, with the augmenting "state" containers SHOULD be avoided, with the
expectation that the base model will be re-released with the expectation that the base model will be re-released with the
state containers marked as deprecated. It is RECOMMENDED to state containers marked as deprecated. It is RECOMMENDED to
augment only the "/foo" hierarchy of the base model. Where this augment only the "/foo" hierarchy of the base model. Where this
recommendation cannot be followed, then any new "state" elements recommendation cannot be followed, any new "state" elements
SHOULD be included in their own module. SHOULD be included in their own module.
4.23.3.1. Temporary Non-NMDA Modules 4.23.3.1. Temporary Non-NMDA Modules
A temporary non-NMDA module allows a non-NMDA-aware client to access A temporary non-NMDA module allows a non-NMDA-aware client to access
operational state from an NMDA-compliant server. It contains the operational state from an NMDA-compliant server. It contains the
top-level "config false" data nodes that would have been defined in a top-level "config false" data nodes that would have been defined in a
legacy YANG module (before NMDA). legacy YANG module (before NMDA).
A server that needs to support both NMDA and non-NMDA clients can A server that needs to support both NMDA and non-NMDA clients can
skipping to change at page 62, line 36 skipping to change at line 2791
A non-NMDA client can use separate "foo" and "foo-state" subtrees, A non-NMDA client can use separate "foo" and "foo-state" subtrees,
except the "foo-state" subtree is located in a different (temporary) except the "foo-state" subtree is located in a different (temporary)
module. The NMDA module can be used by a non-NMDA client to access module. The NMDA module can be used by a non-NMDA client to access
the conventional configuration datastores and the deprecated <get> the conventional configuration datastores and the deprecated <get>
operation to access nested "config false" data nodes. operation to access nested "config false" data nodes.
To create the temporary non-NMDA model from an NMDA model, the To create the temporary non-NMDA model from an NMDA model, the
following steps can be taken: following steps can be taken:
* Change the module name by appending "-state" to the original * Change the module name by appending "-state" to the original
module name module name.
* Change the namespace by appending "-state" to the original * Change the namespace by appending "-state" to the original
namespace value namespace value.
* Change the prefix by appending "-s" to the original prefix value * Change the prefix by appending "-s" to the original prefix value.
* Add an import to the original module (e.g., for typedef * Add an import to the original module (e.g., for typedef
definitions) definitions).
* Retain or create only the top-level nodes that have a "config" * Retain or create only the top-level nodes that have a "config"
statement value "false". These subtrees represent "config false" statement value "false". These subtrees represent "config false"
data nodes that were combined into the configuration subtree; data nodes that were combined into the configuration subtree;
therefore, they are not available to non-NMDA aware clients. Set therefore, they are not available to non-NMDA-aware clients. Set
the "status" statement to "deprecated" for each new node. the "status" statement to "deprecated" for each new node.
* The module description SHOULD clearly identify the module as a * The module description SHOULD clearly identify the module as a
temporary non-NMDA module temporary non-NMDA module.
4.23.3.2. Example: Create a New NMDA Module 4.23.3.2. Example: Create a New NMDA Module
Create an NMDA-compliant module, using combined configuration and Create an NMDA-compliant module, using combined configuration and
state subtrees, whenever possible. state subtrees, whenever possible.
module example-foo { module example-foo {
namespace "urn:example:params:xml:ns:yang:example-foo"; namespace "urn:example:params:xml:ns:yang:example-foo";
prefix "foo"; prefix "foo";
skipping to change at page 67, line 27 skipping to change at line 3011
4.27. Updating YANG Modules (Published versus Unpublished) 4.27. Updating YANG Modules (Published versus Unpublished)
YANG modules can change over time. Typically, new data model YANG modules can change over time. Typically, new data model
definitions are needed to support new features. YANG update rules definitions are needed to support new features. YANG update rules
defined in Section 11 of [RFC7950] MUST be followed for published defined in Section 11 of [RFC7950] MUST be followed for published
modules. They MAY be followed for unpublished modules. modules. They MAY be followed for unpublished modules.
The YANG update rules only apply to published module revisions. Each The YANG update rules only apply to published module revisions. Each
organization will have their own way to identify published work that organization will have their own way to identify published work that
is considered to be stable and unpublished work that is considered to is considered to be stable and unpublished work that is considered to
be unstable. For example, in the IETF, the RFC document is used for be unstable. For example, in the IETF, an RFC is used for published
published work, and the I-D is used for unpublished work. work, and an I-D is used for unpublished work.
4.28. Defining Standard Tags 4.28. Defining Standard Tags
[RFC8819] specifies a method for associating tags with YANG modules. [RFC8819] specifies a method for associating tags with YANG modules.
Tags may be defined and associated at module design time, at Tags may be defined and associated at the time of module design, at
implementation time, or via user administrative control. Design-time the time of implementation, or via user administrative control.
tags are indicated using the module-tag extension statement. Design-time tags are indicated using the module-tag extension
statement.
A module MAY indicate, using module-tag extension statements, a set A module MAY indicate, using module-tag extension statements, a set
of tags that are to be automatically associated with it (i.e., not of tags that are to be automatically associated with it (i.e., not
added through configuration). added through configuration).
module example-module { module example-module {
namespace "https://example.com/yang/example"; namespace "https://example.com/yang/example";
prefix "ex"; prefix "ex";
//... //...
import module-tags { prefix tags; } import module-tags { prefix tags; }
skipping to change at page 68, line 4 skipping to change at line 3036
module example-module { module example-module {
namespace "https://example.com/yang/example"; namespace "https://example.com/yang/example";
prefix "ex"; prefix "ex";
//... //...
import module-tags { prefix tags; } import module-tags { prefix tags; }
tags:module-tag "ietf:some-new-tag"; tags:module-tag "ietf:some-new-tag";
tags:module-tag "ietf:some-other-tag"; tags:module-tag "ietf:some-other-tag";
// ... // ...
} }
Authors can use existing standard tags or use new tags defined in the Authors can use existing standard tags or use new tags defined in the
model definition, as appropriate. For IETF modules, new tags MUST be model definition, as appropriate. For IETF modules, new tags MUST be
assigned in the IANA "IETF YANG Module Tags" registry within the assigned in the IANA "IETF YANG Module Tags" registry within the
"YANG Module Tags" registry [IANA-TAGS]. "YANG Module Tags" registry group [IANA-TAGS].
4.29. Modeling Abstract Data Structures 4.29. Modeling Abstract Data Structures
For contexts where YANG is used to model abstract data structures For contexts where YANG is used to model abstract data structures
(e.g., protocol messages), the use of the "structure" extension (e.g., protocol messages), the use of the "structure" extension
statement [RFC8791] is RECOMMENDED compared to the "yang-data" statement [RFC8791] is RECOMMENDED compared to the "yang-data"
extension statement [RFC8040]. extension statement [RFC8040]. Examples of modules that rely upon
the "structure" extension statement from [RFC8791] can be found in
Examples of modules that rely upon the "structure" extension [RFC9132] or [RFC9195].
statement [RFC8791] are [RFC9132] or [RFC9195].
Abstract data structures can be augmented using the "augment- Abstract data structures can be augmented using the "augment-
structure" statement [RFC8791]. structure" statement [RFC8791]. Examples of modules that augment
abstract data structures can be found in [RFC9244] and [RFC9362].
Examples of modules that augment abstract data structures are
[RFC9244] and [RFC9362].
4.30. IANA-Maintained Modules 4.30. IANA-Maintained Modules
4.30.1. Context 4.30.1. Context
IANA maintains a set of registries that are key for interoperability. IANA maintains a set of registries that are key for interoperability.
The content of these registries are usually available using various The content of these registries is usually available using various
formats (e.g., plain text, XML). However, there were some confusion formats (e.g., plain text or XML). However, there was some confusion
in the past about whether the content of some registries is dependent in the past about whether the content of some registries is dependent
on a specific representation format. For example, Section 5 of on a specific representation format. For example, Section 5 of
[RFC8892] was published to clarify that MIB and YANG modules are [RFC8892] was published to clarify that MIB and YANG modules are
merely additional formats in which the "Interface Types (ifType)" and merely additional formats in which the "Interface Types (ifType)" and
"Tunnel Types (tunnelType)" registries are available. The MIB "Tunnel Types (tunnelType)" registries are available. The MIB
[RFC2863] and YANG modules [RFC7224][RFC8675] are not separate [RFC2863] and YANG modules ([RFC7224] [RFC8675]) are not separate
registries, and the same values are always present in all formats of registries, and the same values are always present in all formats of
the same registry. the same registry.
A design, in which a YANG module includes parameters and values A design in which a YANG module includes parameters and values
directly in a module that is not maintained by IANA while these are directly in a module that is not maintained by IANA while these are
populated in an IANA registry, could lead to ambiguity and maintain populated in an IANA registry could lead to ambiguity and maintain
stale information. Such a design creates another source of stale information. Such a design creates another source of
information that may deviate from the IANA registry as new values are information that may deviate from the IANA registry as new values are
assigned or some values are deprecated. assigned or some values are deprecated.
For the sake of consistency and ability to support new values while For the sake of consistency and the ability to support new values
maintaining IANA registries as the unique authoritative source of while maintaining IANA registries as the unique authoritative source
information, this document recommends the use of IANA-maintained of information, this document recommends the use of IANA-maintained
modules as the single source of information. modules as the single source of information.
The following section provides a set of guidelines for YANG module The following section provides a set of guidelines for YANG module
authors related to the design of IANA-maintained modules. These authors related to the design of IANA-maintained modules. These
guidelines are meant to leverage existing IANA registries and use guidelines are meant to leverage existing IANA registries and use
YANG as another format to present the content of these registries YANG as another format to present the content of these registries
when appropriate. when appropriate.
4.30.2. Guidelines for IANA-Maintained Modules 4.30.2. Guidelines for IANA-Maintained Modules
skipping to change at page 69, line 51 skipping to change at line 3129
| because otherwise the namespace identifier "ietf-dots-telemetry" | because otherwise the namespace identifier "ietf-dots-telemetry"
| must be included when a telemetry attribute is included (e.g., in | must be included when a telemetry attribute is included (e.g., in
| a mitigation efficacy update). The use of "identities" is thus | a mitigation efficacy update). The use of "identities" is thus
| suboptimal from the standpoint of message compactness, as message | suboptimal from the standpoint of message compactness, as message
| compactness is one of the key requirements for DOTS signal channel | compactness is one of the key requirements for DOTS signal channel
| messages. | messages.
Designers of IANA-maintained modules MAY supply the full initial Designers of IANA-maintained modules MAY supply the full initial
version of the module in a specification document that registers the version of the module in a specification document that registers the
module or only a script to be used (including by IANA) for generating module or only a script to be used (including by IANA) for generating
the module (e.g., an XSLT stylesheet as in Appendix A of [RFC9108] or the module (e.g., an Extensible Stylesheet Language Transformations
a Python script as in [RFC9645]). For both cases, the document that (XSLT) stylesheet as in Appendix A of [RFC9108] or a Python script as
defines an IANA-maintained module MUST include a note indicating that in [RFC9645]). For both cases, the document that defines an IANA-
the document is only documenting the initial version of the module maintained module MUST include a note indicating that the document is
and that the authoritative version is to be retrieved from the IANA only documenting the initial version of the module and that the
registry. Also, the IANA-maintained module MUST include the authoritative version is to be retrieved from the IANA registry.
following note indicating the RFC that registered the initial version Also, the IANA-maintained module MUST include the following note
of the IANA-maintained module: indicating the RFC that registered the initial version of the IANA-
maintained module:
The initial version of this YANG module is part of RFC IIII; see | The initial version of this YANG module is part of RFC IIII; see
the RFC itself for full legal notices. | the RFC itself for full legal notices.
It is RECOMMENDED to include the URL from where to retrieve the It is RECOMMENDED to include the URL from where to retrieve the
recent version of the module. When a script is used, the Internet- recent version of the module. When a script is used, the Internet-
Draft that defines an IANA-maintained module have to include an Draft that defines an IANA-maintained module has to include an
appendix with the full script and SHOULD include an appendix with the appendix with the full script and SHOULD include an appendix with the
initial full version of the module. Including such an appendix in initial full version of the module. Including such an appendix in
pre-RFC versions is meant to assess the correctness of the outcome of pre-RFC versions is meant to assess the correctness of the outcome of
the supplied script. The authors MUST include a note to the RFC the supplied script. The authors MUST include a note to the RFC
Editor requesting that the appendix with the initial version of the Editor requesting that the appendix with the initial version of the
module be removed before publication as RFC and that RFC IIII is module be removed before publication as RFC and that RFC IIII is
replaced with the RFC number that is assigned to the document. replaced with the RFC number that is assigned to the document.
Initial versions of IANA-maintained modules that are published in Initial versions of IANA-maintained modules that are published in
RFCs may be misused despite the appropriate language to refer to the RFCs may be misused despite the appropriate language to refer to the
IANA registry to retrieve the up-to-date module. This is problematic IANA registry to retrieve the up-to-date module. This is problematic
for interoperability, e.g., when values are deprecated or are for interoperability, e.g., when values are deprecated or are
associated with a new meaning. associated with a new meaning.
Note: [Style] provides XSLT 1.0 stylesheets and other tools for | Note: [Style] provides XSLT 1.0 stylesheets and other tools for
translating IANA registries to YANG modules. The tools can be | translating IANA registries to YANG modules. The tools can be
used to generate up-to-date revisions of an IANA-maintained module | used to generate up-to-date revisions of an IANA-maintained
based upon the XML representation of an IANA registry. | module based upon the XML representation of an IANA registry.
If an IANA-maintained module is imported by another module, a If an IANA-maintained module is imported by another module, a
normative reference with the IANA URL from where to retrieve the normative reference with the IANA URL from which to retrieve the
IANA-maintained module SHOULD be included. Although not encouraged, IANA-maintained module SHOULD be included. Although not encouraged,
referencing the RFC that defines the initial version of the IANA referencing the RFC that defines the initial version of the IANA
module is acceptable in specific cases (e.g., the imported version is module is acceptable in specific cases (e.g., the imported version is
specifically the initial version, the RFC includes useful description specifically the initial version, the RFC includes useful description
about the usage of the module). about the usage of the module).
Examples of IANA URLs from where to retrieve the latest version of an Examples of IANA URLs from which to retrieve the latest version of an
IANA-maintained module are: [IANA_BGP-L2_URL], [IANA_PW-Types_URL], IANA-maintained module are as follows: [IANA_BGP-L2_URL],
and [IANA_BFD_URL]. "IANA_FOO_URL" is used in the following to refer [IANA_PW-Types_URL], and [IANA_BFD_URL]. "IANA_FOO_URL" is used in
to such URLs. These URLs are expected to be sufficiently permanent the following to refer to such URLs. These URLs are expected to be
and stable. Whenever referencing a specific version of an IANA- sufficiently permanent and stable. Whenever referencing a specific
maintained module is needed, then URLs such as version of an IANA-maintained module is needed, then URLs such as
[IANA_BGP-L2_URL-Revision] are used. "IANA_FOO_URL_With_REV" is used [IANA_BGP-L2_URL-Revision] are used. "IANA_FOO_URL_With_REV" is used
in the following to refer to such URLs. in the following to refer to such URLs.
A template for IANA-maintained modules is provided in Appendix C. A template for IANA-maintained modules is provided in Appendix C.
4.30.3. Guidance for Writing the IANA Considerations for RFCs Defining 4.30.3. Guidance for Writing the IANA Considerations for RFCs Defining
IANA-Maintained Modules IANA-Maintained Modules
In addition to the IANA considerations in Section 3.8, the IANA In addition to the IANA considerations in Section 3.8, the IANA
Considerations Section of an RFC that includes an IANA-maintained Considerations section of an RFC that includes an IANA-maintained
module MUST provide the required instructions for IANA to module MUST provide the required instructions for IANA to
automatically perform the maintenance of that IANA module. These automatically perform the maintenance of that IANA module. These
instructions describe how to proceed with updates to the IANA- instructions describe how to proceed with updates to the IANA-
maintained module that are triggered by a change to the authoritative maintained module that are triggered by a change to the authoritative
registry. Concretely, the IANA Considerations Section SHALL at least registry. Concretely, the IANA Considerations section SHALL at least
provide the following information: provide the following information:
* A request to IANA to add a note to the page displaying the * A request to IANA to add a note to the page displaying the
information about the IANA-maintained module that new values must information about the IANA-maintained module that new values must
not be directly added to the module. These values should be added not be directly added to the module. These values should be added
to an authoritative IANA registry. to an authoritative IANA registry.
* A request to IANA to add a note to the authoritative IANA registry * A request to IANA to add a note to the authoritative IANA registry
to indicate that any change to the registry must be reflected into to indicate that any change to the registry must be reflected into
the corresponding IANA-maintained module. That is, any changes to the corresponding IANA-maintained module. That is, any changes to
the registry must be accompanied by an update to the corresponding the registry must be accompanied by an update to the corresponding
IANA-maintained module. IANA-maintained module.
* Details about the required actions (e.g., add a new "identity" or * Details about the required actions (e.g., add a new "identity" or
"enum" statement) to update the IANA-maintained module to reflect "enum" statement) to update the IANA-maintained module to reflect
changes to an authoritative IANA registry. Typically, these changes to an authoritative IANA registry. Typically, these
details have to include the procedure to create a new "identity" details have to include the procedure to create a new "identity"
statement name and substatements ("base", "status", "description", statement name and substatements ("base", "status", "description",
and "reference") or a new "enum" statement and sub-statements and "reference") or a new "enum" statement and substatements
("value", "status", "description", and "reference"). ("value", "status", "description", and "reference").
- When creating a new "identity" statement name or a new "enum" - When creating a new "identity" statement name or a new "enum"
statement, it is RECOMMENDED to use the same name (if present) statement, it is RECOMMENDED to use the same name (if present)
as recorded in the IANA registry. as recorded in the IANA registry.
- If the name in the IANA registry does not comply with the - If the name in the IANA registry does not comply with the
naming conventions listed in Section 4.3.1, the procedure MUST naming conventions listed in Section 4.3.1, the procedure MUST
detail how IANA can generate legal identifiers from such a detail how IANA can generate legal identifiers from such a
name. Specifically, if the name begins with a number, it is name. Specifically, if the name begins with a number, it is
RECOMMENDED to spell out (i.e., write in full) the number when RECOMMENDED to spell out (i.e., write in full) the number when
used as an identifier. IANA should be provided with used as an identifier. IANA should be provided with
instructions to perform such task. For example, authors of a instructions to perform such a task. For example, authors of a
module with such identifiers have to indicate whether: module with such identifiers have to indicate whether:
o "3des-cbc" should be "three-des-cbc" or rather "triple-des- o "3des-cbc" should be "three-des-cbc" or rather "triple-des-
cbc" to be consistent with Section 6.3 of [RFC4253]. cbc" to be consistent with Section 6.3 of [RFC4253].
o "6to4" should be "sixToFour" as in [RFC7224] or "sixtofour" o "6to4" should be "sixToFour" as in [RFC7224] or "sixtofour"
as in [RFC8675]. as in [RFC8675].
- If a new registration uses an identifier that does not comply - If a new registration uses an identifier that does not comply
with the naming conventions listed in Section 4.3.1, IANA with the naming conventions listed in Section 4.3.1, IANA
should check if a guidance to generate legal identifiers was should check if guidance to generate legal identifiers was
supplied in the RFC that specified the initial version of the supplied in the RFC that specified the initial version of the
module. If no such guidance is available, IANA should check module. If no such guidance is available, IANA should check
the latest revision of the IANA-maintained module for similar the latest revision of the IANA-maintained module for similar
patterns. If all else failed, IANA should seek advice from patterns. If all else fails, IANA should seek advice from
relevant registry experts (e.g., designated experts for a relevant registry experts (e.g., designated experts for a
registry with Expert Review policy (Section 4.5 of [RFC8126]) registry using the Expert Review policy (Section 4.5 of
or responsible Area Director). [RFC8126]) or responsible area director).
* A note that unassigned or reserved values must not be present in * A note that unassigned or reserved values must not be present in
the IANA-maintained module. the IANA-maintained module.
* An instruction whether experimental values should be included in * An instruction whether experimental values should be included in
the IANA-maintained module. If no instruction is provided, the IANA-maintained module. If no instruction is provided,
experimental values MUST NOT be listed in the IANA-maintained experimental values MUST NOT be listed in the IANA-maintained
module. module.
* An instruction about how to generate the "revision" statement. * An instruction about how to generate the "revision" statement.
skipping to change at page 74, line 24 skipping to change at line 3333
"Initial revision."; "Initial revision.";
reference reference
"RFC 8675: A YANG Data Model for Tunnel Interface Types"; "RFC 8675: A YANG Data Model for Tunnel Interface Types";
} }
... ...
identity ipsectunnelmode { identity ipsectunnelmode {
base ift:tunnel; base ift:tunnel;
description description
"IpSec tunnel mode encapsulation."; "IPsec tunnel mode encapsulation.";
reference reference
"RFC 4301: Security Architecture for the Internet Protocol"; "RFC 4301: Security Architecture for the Internet Protocol";
} }
The following example shows how to generate the "revision" statements The following example shows how to generate the "revision" statements
following the guidance in Section 4.30.3.1: following the guidance in Section 4.30.3.1:
revision 2021-04-23 { revision 2021-04-23 {
description description
"Registered tunnelType 19."; "Registered tunnelType 19.";
skipping to change at page 75, line 24 skipping to change at line 3360
revision 2019-11-16 { revision 2019-11-16 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC 8675: A YANG Data Model for Tunnel Interface Types"; "RFC 8675: A YANG Data Model for Tunnel Interface Types";
} }
... ...
identity ipsectunnelmode { identity ipsectunnelmode {
base ift:tunnel; base ift:tunnel;
description description
"IpSec tunnel mode encapsulation."; "IPsec tunnel mode encapsulation.";
reference reference
"RFC 4301: Security Architecture for the Internet Protocol"; "RFC 4301: Security Architecture for the Internet Protocol";
} }
The following templates are to be considered in addition to the The templates in the following subsections are to be considered in
required information that is provided in Section 3.8. addition to the required information that is provided in Section 3.8.
4.30.3.1. Template for IANA-Maintained Modules with Identities 4.30.3.1. Template for IANA-Maintained Modules with Identities
<CODE BEGINS> <CODE BEGINS>
This document defines the initial version of the IANA-maintained This document defines the initial version of the IANA-maintained
"iana-foo" YANG module. The most recent version of the YANG module "iana-foo" YANG module. The most recent version of the YANG module
is available from the "YANG Parameters" registry group is available from the "YANG Parameters" registry group
[IANA-YANG-PARAMETERS]. [IANA-YANG-PARAMETERS].
IANA is requested to add this note to the registry: IANA is requested to add this note to the registry:
New values must not be directly added to the "iana-foo" YANG New values must not be directly added to the "iana-foo" YANG
module. They must instead be added to the "foo" registry. module. They must instead be added to the "foo" registry.
When a value is added to the "foo" registry, a new "identity" When a value is added to the "foo" registry, a new "identity"
statement needs to be added to the "iana-foo" YANG module. The name statement needs to be added to the "iana-foo" YANG module. The name
of the "identity" MUST be the name as provided in the registry. of the "identity" MUST be the name as provided in the registry.
The "identity" statement should have the following The "identity" statement should have the following
sub-statements defined: substatements defined:
"base": Contains 'name-base-identity-defined-in-foo'. "base": Contains 'name-base-identity-defined-in-foo'.
"status": Include only if a registration has been deprecated or "status": Include only if a registration has been deprecated or
obsoleted. IANA "deprecated" maps to YANG status obsoleted. IANA "deprecated" maps to YANG status
"deprecated", and IANA "obsolete" maps to YANG status "deprecated", and IANA "obsolete" maps to YANG status
"obsolete". "obsolete".
"description": Replicates the description from the registry. "description": Replicates the description from the registry.
"reference": Replicates the reference(s) from the registry with "reference": Replicates the reference(s) from the registry with
the title of the document(s) added. the title of the document(s) added.
Unassigned or reserved values are not present in the module. Unassigned or reserved values are not present in the module.
When the "iana-foo" YANG module is updated, a new "revision" When the "iana-foo" YANG module is updated, a new "revision"
statement with a unique revision date must be added in front of the statement with a unique revision date must be added in front of the
existing revision statements. The "revision" statement MUST contain existing "revision" statements. The "revision" statement MUST
both "description" and "reference" substatements as follows. contain both "description" and "reference" substatements as follows.
The "description" substatement captures what changed in the The "description" substatement captures what changed in the
revised version. Typically, the description enumerates the changes revised version. Typically, the description enumerates the changes
such as udpates to existing entries (e.g., update a description or such as udpates to existing entries (e.g., update a description or
a reference) or notes which identities were added or had their status a reference) or notes which identities were added or had their status
changed (e.g., deprecated, discouraged, or obsoleted). changed (e.g., deprecated, discouraged, or obsoleted).
-- When such a description is not feasible, the description varies -- When such a description is not feasible, the description varies
-- on how the update is triggered. -- on how the update is triggered.
-- If the update is triggered by an RFC, insert this text: -- If the update is triggered by an RFC, insert this text:
The "description" substatement should include this text: The "description" substatement should include this text:
skipping to change at page 76, line 45 skipping to change at line 3430
-- If the update is triggered following other IANA registration -- If the update is triggered following other IANA registration
-- policy (Section 4 of [RFC8126]) but not all the values in the -- policy (Section 4 of [RFC8126]) but not all the values in the
-- registry are covered by the same policy, insert this text: -- registry are covered by the same policy, insert this text:
The "description" substatement should include this text: The "description" substatement should include this text:
"Applied updates as specified by the registration policy "Applied updates as specified by the registration policy
<Some_IANA_policy>". <Some_IANA_policy>".
The "reference" substatement points specifically to the published The "reference" substatement points specifically to the published
module (i.e., IANA_FOO_URL_With_REV). It may also point to an module (i.e., IANA_FOO_URL_With_REV). It may also point to an
authoritative event triggering the update to the YANG module. In all authoritative event triggering the update to the YANG module. In all
cases, this event is cited from the underlying IANA registry. If the cases, this event is cited from the underlying IANA registry. If the
update is triggered by an RFC, that RFC must also be included in update is triggered by an RFC, that RFC must also be included in
the "reference" substatement. the "reference" substatement.
-- If a name in the IANA registry does not comply with the -- If a name in the IANA registry does not comply with the
-- YANG naming conventions, add details how IANA can generate -- YANG naming conventions, add details how IANA can generate
-- legal identifiers. For example, if the name begins with -- legal identifiers. For example, if the name begins with
-- a number, indicate a preference to spell out the number when -- a number, indicate a preference to spell out the number when
-- used as an identifier. -- used as an identifier.
IANA is requested to add this note to [reference-to-the-iana-foo- IANA is requested to add this note to [reference-to-the-iana-foo-
registry]: registry]:
When this registry is modified, the YANG module "iana-foo" When this registry is modified, the YANG module "iana-foo"
[IANA_FOO_URL] must be updated as defined in RFC IIII. [IANA_FOO_URL] must be updated as defined in RFC IIII.
<CODE ENDS> <CODE ENDS>
4.30.3.2. Template for IANA-Maintained Modules with Enumerations 4.30.3.2. Template for IANA-Maintained Modules with Enumerations
<CODE BEGINS> <CODE BEGINS>
This document defines the initial version of the IANA-maintained This document defines the initial version of the IANA-maintained
"iana-foo" YANG module. The most recent version of the YANG module "iana-foo" YANG module. The most recent version of the YANG module
is available from the "YANG Parameters" registry group is available from the "YANG Parameters" registry group
[IANA-YANG-PARAMETERS]. [IANA-YANG-PARAMETERS].
IANA is requested to add this note to the registry: IANA is requested to add this note to the registry:
New values must not be directly added to the "iana-foo" YANG New values must not be directly added to the "iana-foo" YANG
module. They must instead be added to the "foo" registry. module. They must instead be added to the "foo" registry.
When a value is added to the "foo" registry, a new "enum" statement When a value is added to the "foo" registry, a new "enum" statement
must be added to the "iana-foo" YANG module. The "enum" statement, must be added to the "iana-foo" YANG module. The "enum" statement,
and sub-statements thereof, should be defined: and substatements thereof, should be defined:
"enum": Replicates a name from the registry. "enum": Replicates a name from the registry.
"value": Contains the decimal value of the IANA-assigned "value": Contains the decimal value of the IANA-assigned
value. value.
"status": Is included only if a registration has been "status": Is included only if a registration has been
deprecated or obsoleted. IANA "deprecated" maps deprecated or obsoleted. IANA "deprecated" maps
to YANG status "deprecated", and IANA "obsolete" to YANG status "deprecated", and IANA "obsolete"
maps to YANG status "obsolete". maps to YANG status "obsolete".
"description": Replicates the description from the registry. "description": Replicates the description from the registry.
"reference": Replicates the reference(s) from the registry with "reference": Replicates the reference(s) from the registry with
the title of the document(s) added. the title of the document(s) added.
Unassigned or reserved values are not present in the module. Unassigned or reserved values are not present in the module.
When the "iana-foo" YANG module is updated, a new "revision" When the "iana-foo" YANG module is updated, a new "revision"
statement with a unique revision date needs to be added in front of statement with a unique revision date needs to be added in front of
the existing revision statements. The "revision" statement MUST the existing "revision" statements. The "revision" statement MUST
contain both "description" and "reference" substatements as follows. contain both "description" and "reference" substatements as follows.
The "description" substatement captures what changed in the The "description" substatement captures what changed in the
revised version. Typically, the description enumerates the changes revised version. Typically, the description enumerates the changes
such as udpates to existing entries (e.g., update a description or such as udpates to existing entries (e.g., update a description or
a reference) or notes which "enums" were added or had their status a reference) or notes which "enums" were added or had their status
changed (e.g., deprecated, discouraged, or obsoleted). changed (e.g., deprecated, discouraged, or obsoleted).
-- When such a description is not feasible, the description varies -- When such a description is not feasible, the description varies
-- on how the update is triggered. -- on how the update is triggered.
-- If the update is triggered by an RFC, insert this text: -- If the update is triggered by an RFC, insert this text:
The "description" substatement should include this text: The "description" substatement should include this text:
skipping to change at page 78, line 29 skipping to change at line 3513
-- If the update is triggered following other IANA registration -- If the update is triggered following other IANA registration
-- policy (Section 4 of [RFC8126]) but not all the values in the -- policy (Section 4 of [RFC8126]) but not all the values in the
-- registry are covered by the same policy, insert this text: -- registry are covered by the same policy, insert this text:
The "description" substatement should include this text: The "description" substatement should include this text:
"Applied updates as specified by the registration policy "Applied updates as specified by the registration policy
<Some_IANA_policy>". <Some_IANA_policy>".
The "reference" substatement points specifically to the published The "reference" substatement points specifically to the published
module (i.e., IANA_FOO_URL_With_REV). It may also point to an module (i.e., IANA_FOO_URL_With_REV). It may also point to an
authoritative event triggering the update to the YANG module. In all authoritative event triggering the update to the YANG module. In all
cases, this event is cited from the underlying IANA registry. If the cases, this event is cited from the underlying IANA registry. If the
update is triggered by an RFC, that RFC must also be included in update is triggered by an RFC, that RFC must also be included in
the "reference" substatement. the "reference" substatement.
-- If a name in the IANA registry does not comply with the -- If a name in the IANA registry does not comply with the
-- YANG naming conventions, add details how IANA can generate -- YANG naming conventions, add details how IANA can generate
-- legal identifiers. For example, if the name begins with -- legal identifiers. For example, if the name begins with
-- a number, indicate a preference to spell out the number when -- a number, indicate a preference to spell out the number when
-- used as an identifier. -- used as an identifier.
IANA is requested to add this note to [reference-to-the-iana-foo- IANA is requested to add this note to [reference-to-the-iana-foo-
registry]: registry]:
When this registry is modified, the YANG module "iana-foo" When this registry is modified, the YANG module "iana-foo"
[IANA_FOO_URL] must be updated as defined in RFC IIII. [IANA_FOO_URL] must be updated as defined in RFC IIII.
<CODE ENDS> <CODE ENDS>
5. IANA Considerations 5. IANA Considerations
5.1. YANG Modules 5.1. YANG Modules
The following registration in the "ns" registry of the "IETF XML The following registration in the "ns" registry of the "IETF XML
Registry" [RFC3688] was detailed in [RFC8407]. This document Registry" registry group [RFC3688] was detailed in [RFC8407]. IANA
requests IANA to update this registration to reference this document. has updated this registration to reference this document.
URI: urn:ietf:params:xml:ns:yang:ietf-template URI: urn:ietf:params:xml:ns:yang:ietf-template
Registrant Contact: The IESG. Registrant Contact: The IESG
XML: N/A, the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
IANA is requested to register the following URI in the "ns" registry IANA has registered the following URI in the "ns" registry within the
within the "IETF XML Registry" group [RFC3688]: "IETF XML Registry" registry group [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:iana-template URI: urn:ietf:params:xml:ns:yang:iana-template
Registrant Contact: The IESG. Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
This document requests IANA to register the following YANG modules in IANA has registered the following YANG modules in the "YANG Module
the "YANG Module Names" registry [RFC6020] within the "YANG Names" registry [RFC6020] within the "YANG Parameters" registry
Parameters" registry group. group.
Name: ietf-template Name: ietf-template
Maintained by IANA? N Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-template Namespace: urn:ietf:params:xml:ns:yang:ietf-template
Prefix: temp Prefix: temp
Reference: RFC AAAA Reference: RFC 9907
Name: iana-template Name: iana-template
Maintained by IANA? N Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:iana-template Namespace: urn:ietf:params:xml:ns:yang:iana-template
Prefix: iana-foo Prefix: iana-foo
Reference: RFC AAAA Reference: RFC 9907
5.2. Update YANG Parameters Registry Group 5.2. Update in YANG Parameters Registry Group
Also, this document requests IANA to update the RFC8407 reference for For the references of the "YANG Module Names" registry under the
the "YANG Module Names" registry under the "YANG Parameters" registry "YANG Parameters" registry group, IANA has updated [RFC8407] to this
group to point to the RFC number that will be assigned to this document, as it contains the template necessary for registration in
document as it contains the template necessary for registration in
Appendix B. Appendix B.
5.3. IANA-Maintained Modules 5.3. IANA-Maintained Modules
IANA should refer to Section 4.30.3 for information necessary to IANA should refer to Section 4.30.3 for information necessary to
populate "revision" statements and "identity" and "enum" populate "revision" statements and "identity" and "enum"
substatements in IANA-maintained modules. These considerations cover substatements in IANA-maintained modules. These considerations cover
both the creation and maintenance of an IANA-mainatined module. In both the creation and maintenance of an IANA-mainatined module. In
particular, the following should be noted: particular, the following should be noted:
skipping to change at page 80, line 47 skipping to change at line 3625
defined with the YANG data modeling language. It does not introduce defined with the YANG data modeling language. It does not introduce
any new or increased security risks. any new or increased security risks.
8. References 8. References
8.1. Normative References 8.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>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/rfc/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights [RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights
Contributors Provide to the IETF Trust", BCP 78, RFC 5378, Contributors Provide to the IETF Trust", BCP 78, RFC 5378,
DOI 10.17487/RFC5378, November 2008, DOI 10.17487/RFC5378, November 2008,
<https://www.rfc-editor.org/rfc/rfc5378>. <https://www.rfc-editor.org/info/rfc5378>.
[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>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/rfc/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/rfc/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG",
RFC 7952, DOI 10.17487/RFC7952, August 2016, RFC 7952, DOI 10.17487/RFC7952, August 2016,
<https://www.rfc-editor.org/rfc/rfc7952>. <https://www.rfc-editor.org/info/rfc7952>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/rfc/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341, Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018, DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/rfc/rfc8341>. <https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/rfc/rfc8342>. <https://www.rfc-editor.org/info/rfc8342>.
[RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data [RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data
Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, Structure Extensions", RFC 8791, DOI 10.17487/RFC8791,
June 2020, <https://www.rfc-editor.org/rfc/rfc8791>. June 2020, <https://www.rfc-editor.org/info/rfc8791>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and "Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/rfc/rfc8792>. <https://www.rfc-editor.org/info/rfc8792>.
[RFC8819] Hopps, C., Berger, L., and D. Bogdanovic, "YANG Module [RFC8819] Hopps, C., Berger, L., and D. Bogdanovic, "YANG Module
Tags", RFC 8819, DOI 10.17487/RFC8819, January 2021, Tags", RFC 8819, DOI 10.17487/RFC8819, January 2021,
<https://www.rfc-editor.org/rfc/rfc8819>. <https://www.rfc-editor.org/info/rfc8819>.
[W3C.REC-xpath] [W3C.REC-xpath]
Clark, J. and S. DeRose, "XML Path Language (XPath) Clark, J., Ed. and S. DeRose, Ed., "XML Path Language
Version 1.0", W3C Recommendation REC-xpath-19991116, (XPath) Version 1.0", W3C Recommendation, 16 November
November 1999, 1999, <https://www.w3.org/TR/1999/REC-xpath-19991116>.
<https://www.w3.org/TR/1999/REC-xpath-19991116>.
8.2. Informative References 8.2. Informative References
[Err5693] RFC Errata, Erratum ID 5693, RFC 8407,
<https://www.rfc-editor.org/errata/eid5693>.
[Err5800] RFC Errata, Erratum ID 5800, RFC 8407,
<https://www.rfc-editor.org/errata/eid5800>.
[Err6899] RFC Errata, Erratum ID 6899, RFC 8407,
<https://www.rfc-editor.org/errata/eid6899>.
[Err7416] RFC Errata, Erratum ID 7416, RFC 8407,
<https://www.rfc-editor.org/errata/eid7416>.
[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/>.
[IANA-TAGS] [IANA-TAGS]
IANA, "YANG Module Tags", IANA, "YANG Module Tags",
<https://www.iana.org/assignments/yang-module-tags/>. <https://www.iana.org/assignments/yang-module-tags/>.
[IANA-XML] IANA, "IETF XML Registry", [IANA-XML] IANA, "IETF XML Registry",
<https://www.iana.org/assignments/xml-registry/>. <https://www.iana.org/assignments/xml-registry/>.
[IANA-YANG-PARAMETERS] [IANA-YANG-PARAMETERS]
"YANG Parameters", n.d., IANA, "YANG Parameters",
<https://www.iana.org/assignments/yang-parameters>. <https://www.iana.org/assignments/yang-parameters>.
[IANA_BFD_URL] [IANA_BFD_URL]
IANA, "iana-bfd-types YANG Module", IANA, "iana-bfd-types YANG Module",
<https://www.iana.org/assignments/iana-bfd-types/iana-bfd- <https://www.iana.org/assignments/iana-bfd-types>.
types.xhtml>.
[IANA_BGP-L2_URL] [IANA_BGP-L2_URL]
IANA, "iana-bgp-l2-encaps YANG Module", IANA, "iana-bgp-l2-encaps YANG Module",
<https://www.iana.org/assignments/iana-bgp-l2-encaps/iana- <https://www.iana.org/assignments/iana-bgp-l2-encaps>.
bgp-l2-encaps.xhtml>.
[IANA_BGP-L2_URL-Revision] [IANA_BGP-L2_URL-Revision]
IANA, "iana-bfd-types@2021-10-21.yang", IANA, "iana-bfd-types@2021-10-21.yang",
<https://www.iana.org/assignments/yang-parameters/iana- <https://www.iana.org/assignments/yang-parameters/iana-
bfd-types@2021-10-21.yang>. bfd-types@2021-10-21.yang>.
[IANA_PW-Types_URL] [IANA_PW-Types_URL]
IANA, "iana-pseudowire-types YANG Module", IANA, "iana-pseudowire-types YANG Module",
<https://www.iana.org/assignments/iana-pseudowire-types/ <https://www.iana.org/assignments/iana-pseudowire-types>.
iana-pseudowire-types.xhtml>.
[IANA_Tunnel_Type_URL] [IANA_Tunnel_Type_URL]
IANA, "iana-tunnel-type YANG Module", IANA, "iana-tunnel-type YANG Module",
<https://www.iana.org/assignments/iana-tunnel-type/iana- <https://www.iana.org/assignments/iana-tunnel-type>.
tunnel-type.xhtml>.
[ID-Guidelines] [ID-Guidelines]
IETF, "Guidelines to Authors of Internet-Drafts", n.d., IETF, "Content guidelines overview",
<https://authors.ietf.org/en/content-guidelines-overview>. <https://authors.ietf.org/en/content-guidelines-overview>.
[RFC-STYLE]
RFC Editor, "Style Guide",
<https://www.rfc-editor.org/styleguide/>.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
<https://www.rfc-editor.org/rfc/rfc2026>. <https://www.rfc-editor.org/info/rfc2026>.
[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999,
<https://www.rfc-editor.org/rfc/rfc2606>. <https://www.rfc-editor.org/info/rfc2606>.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000,
<https://www.rfc-editor.org/rfc/rfc2863>. <https://www.rfc-editor.org/info/rfc2863>.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849, Reserved for Documentation", RFC 3849,
DOI 10.17487/RFC3849, July 2004, DOI 10.17487/RFC3849, July 2004,
<https://www.rfc-editor.org/rfc/rfc3849>. <https://www.rfc-editor.org/info/rfc3849>.
[RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", [RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme",
RFC 4151, DOI 10.17487/RFC4151, October 2005, RFC 4151, DOI 10.17487/RFC4151, October 2005,
<https://www.rfc-editor.org/rfc/rfc4151>. <https://www.rfc-editor.org/info/rfc4151>.
[RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers of [RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers of
MIB Documents", BCP 111, RFC 4181, DOI 10.17487/RFC4181, MIB Documents", BCP 111, RFC 4181, DOI 10.17487/RFC4181,
September 2005, <https://www.rfc-editor.org/rfc/rfc4181>. September 2005, <https://www.rfc-editor.org/info/rfc4181>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
January 2006, <https://www.rfc-editor.org/rfc/rfc4252>. January 2006, <https://www.rfc-editor.org/info/rfc4252>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/rfc/rfc4253>. January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for [RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for
Documentation Use", RFC 5398, DOI 10.17487/RFC5398, Documentation Use", RFC 5398, DOI 10.17487/RFC5398,
December 2008, <https://www.rfc-editor.org/rfc/rfc5398>. December 2008, <https://www.rfc-editor.org/info/rfc5398>.
[RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for [RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for
Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August
2009, <https://www.rfc-editor.org/rfc/rfc5612>. 2009, <https://www.rfc-editor.org/info/rfc5612>.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
Reserved for Documentation", RFC 5737, Reserved for Documentation", RFC 5737,
DOI 10.17487/RFC5737, January 2010, DOI 10.17487/RFC5737, January 2010,
<https://www.rfc-editor.org/rfc/rfc5737>. <https://www.rfc-editor.org/info/rfc5737>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/rfc/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface [RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<https://www.rfc-editor.org/rfc/rfc7223>. <https://www.rfc-editor.org/info/rfc7223>.
[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module",
RFC 7224, DOI 10.17487/RFC7224, May 2014, RFC 7224, DOI 10.17487/RFC7224, May 2014,
<https://www.rfc-editor.org/rfc/rfc7224>. <https://www.rfc-editor.org/info/rfc7224>.
[RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for [RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for
SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407, SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407,
December 2014, <https://www.rfc-editor.org/rfc/rfc7407>. December 2014, <https://www.rfc-editor.org/info/rfc7407>.
[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
RFC 7951, DOI 10.17487/RFC7951, August 2016, RFC 7951, DOI 10.17487/RFC7951, August 2016,
<https://www.rfc-editor.org/rfc/rfc7951>. <https://www.rfc-editor.org/info/rfc7951>.
[RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module
Classification", RFC 8199, DOI 10.17487/RFC8199, July Classification", RFC 8199, DOI 10.17487/RFC8199, July
2017, <https://www.rfc-editor.org/rfc/rfc8199>. 2017, <https://www.rfc-editor.org/info/rfc8199>.
[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
"YANG Data Model for L3VPN Service Delivery", RFC 8299, "YANG Data Model for L3VPN Service Delivery", RFC 8299,
DOI 10.17487/RFC8299, January 2018, DOI 10.17487/RFC8299, January 2018,
<https://www.rfc-editor.org/rfc/rfc8299>. <https://www.rfc-editor.org/info/rfc8299>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/rfc/rfc8309>. <https://www.rfc-editor.org/info/rfc8309>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/rfc/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface [RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/rfc/rfc8343>. <https://www.rfc-editor.org/info/rfc8343>.
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349, Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018, DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/rfc/rfc8349>. <https://www.rfc-editor.org/info/rfc8349>.
[RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of
Documents Containing YANG Data Models", BCP 216, RFC 8407, Documents Containing YANG Data Models", BCP 216, RFC 8407,
DOI 10.17487/RFC8407, October 2018, DOI 10.17487/RFC8407, October 2018,
<https://www.rfc-editor.org/rfc/rfc8407>. <https://www.rfc-editor.org/info/rfc8407>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG
Data Model for Layer 2 Virtual Private Network (L2VPN) Data Model for Layer 2 Virtual Private Network (L2VPN)
Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October
2018, <https://www.rfc-editor.org/rfc/rfc8466>. 2018, <https://www.rfc-editor.org/info/rfc8466>.
[RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair,
"YANG Data Model for Network Access Control Lists (ACLs)", "YANG Data Model for Network Access Control Lists (ACLs)",
RFC 8519, DOI 10.17487/RFC8519, March 2019, RFC 8519, DOI 10.17487/RFC8519, March 2019,
<https://www.rfc-editor.org/rfc/rfc8519>. <https://www.rfc-editor.org/info/rfc8519>.
[RFC8675] Boucadair, M., Farrer, I., and R. Asati, "A YANG Data [RFC8675] Boucadair, M., Farrer, I., and R. Asati, "A YANG Data
Model for Tunnel Interface Types", RFC 8675, Model for Tunnel Interface Types", RFC 8675,
DOI 10.17487/RFC8675, November 2019, DOI 10.17487/RFC8675, November 2019,
<https://www.rfc-editor.org/rfc/rfc8675>. <https://www.rfc-editor.org/info/rfc8675>.
[RFC8892] Thaler, D. and D. Romascanu, "Guidelines and Registration [RFC8892] Thaler, D. and D. Romascanu, "Guidelines and Registration
Procedures for Interface Types and Tunnel Types", Procedures for Interface Types and Tunnel Types",
RFC 8892, DOI 10.17487/RFC8892, August 2020, RFC 8892, DOI 10.17487/RFC8892, August 2020,
<https://www.rfc-editor.org/rfc/rfc8892>. <https://www.rfc-editor.org/info/rfc8892>.
[RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and
L. Geng, "A Framework for Automating Service and Network L. Geng, "A Framework for Automating Service and Network
Management with YANG", RFC 8969, DOI 10.17487/RFC8969, Management with YANG", RFC 8969, DOI 10.17487/RFC8969,
January 2021, <https://www.rfc-editor.org/rfc/rfc8969>. January 2021, <https://www.rfc-editor.org/info/rfc8969>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>. <https://www.rfc-editor.org/info/rfc9000>.
[RFC9108] Lhotka, L. and P. Špaček, "YANG Types for DNS Classes and [RFC9108] Lhotka, L. and P. Špaček, "YANG Types for DNS Classes and
Resource Record Types", RFC 9108, DOI 10.17487/RFC9108, Resource Record Types", RFC 9108, DOI 10.17487/RFC9108,
September 2021, <https://www.rfc-editor.org/rfc/rfc9108>. September 2021, <https://www.rfc-editor.org/info/rfc9108>.
[RFC9129] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, [RFC9129] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem,
"YANG Data Model for the OSPF Protocol", RFC 9129, "YANG Data Model for the OSPF Protocol", RFC 9129,
DOI 10.17487/RFC9129, October 2022, DOI 10.17487/RFC9129, October 2022,
<https://www.rfc-editor.org/rfc/rfc9129>. <https://www.rfc-editor.org/info/rfc9129>.
[RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K, [RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K,
"Distributed Denial-of-Service Open Threat Signaling "Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Specification", RFC 9132, (DOTS) Signal Channel Specification", RFC 9132,
DOI 10.17487/RFC9132, September 2021, DOI 10.17487/RFC9132, September 2021,
<https://www.rfc-editor.org/rfc/rfc9132>. <https://www.rfc-editor.org/info/rfc9132>.
[RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., [RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M.,
Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model
for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182, for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182,
February 2022, <https://www.rfc-editor.org/rfc/rfc9182>. February 2022, <https://www.rfc-editor.org/info/rfc9182>.
[RFC9195] Lengyel, B. and B. Claise, "A File Format for YANG [RFC9195] Lengyel, B. and B. Claise, "A File Format for YANG
Instance Data", RFC 9195, DOI 10.17487/RFC9195, February Instance Data", RFC 9195, DOI 10.17487/RFC9195, February
2022, <https://www.rfc-editor.org/rfc/rfc9195>. 2022, <https://www.rfc-editor.org/info/rfc9195>.
[RFC9244] Boucadair, M., Ed., Reddy.K, T., Ed., Doron, E., Chen, M., [RFC9244] Boucadair, M., Ed., Reddy.K, T., Ed., Doron, E., Chen, M.,
and J. Shallow, "Distributed Denial-of-Service Open Threat and J. Shallow, "Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry", RFC 9244, Signaling (DOTS) Telemetry", RFC 9244,
DOI 10.17487/RFC9244, June 2022, DOI 10.17487/RFC9244, June 2022,
<https://www.rfc-editor.org/rfc/rfc9244>. <https://www.rfc-editor.org/info/rfc9244>.
[RFC9291] Boucadair, M., Ed., Gonzalez de Dios, O., Ed., Barguil, [RFC9291] Boucadair, M., Ed., Gonzalez de Dios, O., Ed., Barguil,
S., and L. Munoz, "A YANG Network Data Model for Layer 2 S., and L. Munoz, "A YANG Network Data Model for Layer 2
VPNs", RFC 9291, DOI 10.17487/RFC9291, September 2022, VPNs", RFC 9291, DOI 10.17487/RFC9291, September 2022,
<https://www.rfc-editor.org/rfc/rfc9291>. <https://www.rfc-editor.org/info/rfc9291>.
[RFC9362] Boucadair, M. and J. Shallow, "Distributed Denial-of- [RFC9362] Boucadair, M. and J. Shallow, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Signal Channel Service Open Threat Signaling (DOTS) Signal Channel
Configuration Attributes for Robust Block Transmission", Configuration Attributes for Robust Block Transmission",
RFC 9362, DOI 10.17487/RFC9362, February 2023, RFC 9362, DOI 10.17487/RFC9362, February 2023,
<https://www.rfc-editor.org/rfc/rfc9362>. <https://www.rfc-editor.org/info/rfc9362>.
[RFC9637] Huston, G. and N. Buraglio, "Expanding the IPv6 [RFC9637] Huston, G. and N. Buraglio, "Expanding the IPv6
Documentation Space", RFC 9637, DOI 10.17487/RFC9637, Documentation Space", RFC 9637, DOI 10.17487/RFC9637,
August 2024, <https://www.rfc-editor.org/rfc/rfc9637>. August 2024, <https://www.rfc-editor.org/info/rfc9637>.
[RFC9645] Watsen, K., "YANG Groupings for TLS Clients and TLS [RFC9645] Watsen, K., "YANG Groupings for TLS Clients and TLS
Servers", RFC 9645, DOI 10.17487/RFC9645, October 2024, Servers", RFC 9645, DOI 10.17487/RFC9645, October 2024,
<https://www.rfc-editor.org/rfc/rfc9645>. <https://www.rfc-editor.org/info/rfc9645>.
[Style] "IANA YANG", n.d., <https://github.com/llhotka/iana-yang>. [Style] "IANA YANG", commit 3a6cb69, December 2021,
<https://github.com/llhotka/iana-yang>.
Appendix A. Module Review Checklist Appendix A. Module Review Checklist
This section is adapted from [RFC4181]. This section is adapted from [RFC4181].
The purpose of a YANG module review is to review the YANG module for The purpose of a YANG module review is to review the YANG module for
both technical correctness and adherence to IETF documentation both technical correctness and adherence to IETF documentation
requirements. The following checklist may be helpful when reviewing requirements. The following checklist may be helpful when reviewing
an I-D: an I-D:
* I-D Boilerplate -- verify that the document contains the required * I-D Boilerplate: Verify that the document contains the required
I-D boilerplate (see <https://www.ietf.org/id-info/ I-D boilerplate (see <https://www.ietf.org/id-info/
guidelines.html>), including the appropriate statement to permit guidelines.html>), including the appropriate statement to permit
publication as an RFC, and that the I-D boilerplate does not publication as an RFC, and that the I-D boilerplate does not
contain references or section numbers. contain references or section numbers.
* Abstract -- verify that the abstract does not contain references, * Abstract: Verify that the abstract does not contain references,
that it does not have a section number, and that its content that it does not have a section number, and that its content
follows the guidelines in <https://www.ietf.org/id-info/ follows the guidelines in <https://www.ietf.org/id-info/
guidelines.html>. guidelines.html>.
* Copyright Notice -- verify that the document has the appropriate * Copyright Notice: Verify that the document has the appropriate
text regarding the rights that document contributors provide to text regarding the rights that document contributors provide to
the IETF Trust [RFC5378]. Verify that it contains the full IETF the IETF Trust [RFC5378]. Verify that it contains the full IETF
Trust copyright notice at the beginning of the document. The IETF Trust copyright notice at the beginning of the document. The IETF
Trust Legal Provisions (TLP) can be found at: Trust Legal Provisions (TLP) can be found at:
<https://trustee.ietf.org/license-info/> <https://trustee.ietf.org/license-info/>
* Security Considerations section -- If none of the modules in the * Security Considerations section: If none of the modules in the
document falls under the exceptions in Section 3.7 (e.g., use YANG document falls under the exceptions in Section 3.7 (e.g., use YANG
data structure), verify that the section is modeled after the data structure), verify that the section is modeled after the
latest approved template from the Operations and Management (OPS) latest approved template from the Operations and Management (OPS)
area website (see <https://wiki.ietf.org/group/ops/yang-security- area website (see <https://wiki.ietf.org/group/ops/yang-security-
guidelines>) and that the guidelines therein have been followed. guidelines>) and that the guidelines therein have been followed.
* IANA Considerations section -- this section must always be * IANA Considerations section: This section must always be present.
present. For each module within the document, ensure that the For each module within the document, ensure that the IANA
IANA Considerations section contains entries for the following Considerations section contains entries for the following IANA
IANA registries: registries:
XML Namespace Registry: Register the YANG module namespace. - XML Namespace Registry: Register the YANG module namespace.
YANG Module Registry: Register the YANG module name, prefix, - YANG Module Registry: Register the YANG module name, prefix,
namespace, and RFC number, according to the rules specified in namespace, and RFC number according to the rules specified in
[RFC6020]. [RFC6020].
* References -- verify that the references are properly divided * References: Verify that the references are properly divided
between normative and informative references, that RFCs 2119 and between normative and informative references, that RFCs 2119 and
8174 are included as normative references if the terminology 8174 are included as normative references if the terminology
defined therein is used in the document, that all references defined therein is used in the document, that all references
required by the boilerplate are present, that all YANG modules required by the boilerplate are present, that all YANG modules
containing imported items are cited as normative references, and containing imported items are cited as normative references, and
that all citations point to the most current RFCs, unless there is that all citations point to the most current RFCs, unless there is
a valid reason to do otherwise (for example, it is okay to include a valid reason to do otherwise (for example, it is okay to include
an informative reference to a previous version of a specification an informative reference to a previous version of a specification
to help explain a feature included for backward compatibility). to help explain a feature included for backward compatibility).
Be sure citations for all imported modules are present somewhere Be sure citations for all imported modules are present somewhere
in the document text (outside the YANG module). If a YANG module in the document text (outside the YANG module). If a YANG module
contains reference or "description" statements that refer to an contains "reference" or "description" statements that refer to an
I-D, then the I-D is included as an informative reference. I-D, then the I-D is included as an informative reference.
* License -- verify that the document contains the Revised BSD * License: Verify that the document contains the Revised BSD License
License in each YANG module or submodule. Some guidelines related in each YANG module or submodule. Some guidelines related to this
to this requirement are described in Section 3.1. Make sure that requirement are described in Section 3.1. Make sure that the
the correct year is used in all copyright dates. Use the approved correct year is used in all copyright dates. Use the approved
text from the latest TLP document, which can be found at: text from the latest TLP document, which can be found at:
<https://trustee.ietf.org/license-info/> <https://trustee.ietf.org/license-info/>
* Other Issues -- check for any issues mentioned in * Other Issues: Check for any issues mentioned in
<https://www.ietf.org/id-info/checklist.html> that are not covered <https://www.ietf.org/id-info/checklist.html> that are not covered
elsewhere. elsewhere.
* Technical Content -- review the actual technical content for * Technical Content: Review the actual technical content for
compliance with the guidelines in this document. The use of a compliance with the guidelines in this document. The use of a
YANG module compiler is recommended when checking for syntax YANG module compiler is recommended when checking for syntax
errors. A list of freely available tools and other information, errors. A list of freely available tools and other information,
including formatting advice, can be found at: including formatting advice, can be found at:
<https://wiki.ietf.org/group/netconf> and
<https://wiki.ietf.org/group/netconf>
and
<https://wiki.ietf.org/group/netmod> <https://wiki.ietf.org/group/netmod>
Checking for correct syntax, however, is only part of the job. It Checking for correct syntax, however, is only part of the job. It
is just as important to actually read the YANG module document is just as important to actually read the YANG module document
from the point of view of a potential implementor. It is from the point of view of a potential implementor. It is
particularly important to check that "description" statements are particularly important to check that "description" statements are
sufficiently clear and unambiguous to allow interoperable sufficiently clear and unambiguous to allow interoperable
implementations to be created. implementations to be created.
Appendix B. Template for IETF Modules Appendix B. Template for IETF Modules
skipping to change at page 90, line 9 skipping to change at line 4057
contact contact
"WG Web: <http://datatracker.ietf.org/wg/your-wg-name/> "WG Web: <http://datatracker.ietf.org/wg/your-wg-name/>
WG List: <mailto:your-wg-name@ietf.org> WG List: <mailto:your-wg-name@ietf.org>
Editor: your-name Editor: your-name
<mailto:your-email@example.com>"; <mailto:your-email@example.com>";
// replace the first sentence in this description statement. // replace the first sentence in this description statement.
// replace the copyright notice with the most recent // replace the copyright notice with the most recent
// version, if it has been updated since the publication // version, if it has been updated since the publication
// of this document // of this document.
description description
"This module defines a template for other YANG modules. "This module defines a template for other YANG modules.
Copyright (c) <insert year> IETF Trust and the persons Copyright (c) <insert year> IETF Trust and the persons
identified as authors of the code. All rights reserved. identified as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License to the license terms contained in, the Revised BSD License
skipping to change at page 90, line 31 skipping to change at line 4079
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
All revisions of IETF and IANA published modules can be found All revisions of IETF and IANA published modules can be found
at the YANG Parameters registry group at the YANG Parameters registry group
(https://www.iana.org/assignments/yang-parameters). (https://www.iana.org/assignments/yang-parameters).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX/YYYY with actual RFC number and remove // RFC Ed.: replace XXXX with actual RFC number and remove
// this note // this note
// replace 'date-revision' with the module publication date // replace 'date-revision' with the module publication date
// the format is (YYYY-MM-DD) // the format is (YYYY-MM-DD)
revision date-revision { revision date-revision {
description description
"What changed in this revision."; "What changed in this revision.";
reference reference
"RFC XXXX: <Replace With Document Title>"; "RFC XXXX: <Replace With Document Title>";
} }
// RFC Ed.: Update with the RFC number and title // RFC Ed.: Update with the RFC number and title
// of the RFC that defined the initial version of // of the RFC that defined the initial version of
// the module and remove this note // the module and remove this note
revision date-initial { revision date-initial {
description description
"Initial version"; "Initial version.";
reference reference
"RFC YYYY: <Replace With Document Title>"; "RFC XXXX: <Replace With Document Title>";
} }
// extension statements // extension statements
// feature statements // feature statements
// identity statements // identity statements
// typedef statements // typedef statements
// grouping statements // grouping statements
// data definition statements // data definition statements
// augment statements // augment statements
// rpc statements // rpc statements
skipping to change at page 92, line 43 skipping to change at line 4187
// replace with the registry name and the URL of the IANA registry // replace with the registry name and the URL of the IANA registry
reference reference
"Registry Name (URL)"; "Registry Name (URL)";
// replace 'date-revision' with the module publication date // replace 'date-revision' with the module publication date
// the format is (YYYY-MM-DD) // the format is (YYYY-MM-DD)
revision date-revision { revision date-revision {
description description
"Indicates the list of changes per Section 4.30.3 of RFCAAAA."; "Indicates the list of changes per Section 4.30.3 of RFC 9907";
reference reference
"URL of the latest version of the module "URL of the latest version of the module
(if any) list the authoritative event (e.g., RFC) that (if any) list the authoritative event (e.g., RFC) that
triggered the update to the YANG module"; triggered the update to the YANG module";
} }
// replace 'date-initial' with the module publication date // replace 'date-initial' with the module publication date
// the format is (YYYY-MM-DD) // the format is (YYYY-MM-DD)
revision date-initial { revision date-initial {
description description
"Initial version"; "Initial version.";
reference reference
"URL of the published initial version of the module "URL of the published initial version of the module
RFC IIII: RFC Title"; RFC IIII: RFC Title";
// RFC Ed.: Update with the RFC number and title // RFC Ed.: Update with the RFC number and title
// of the RFC that defined the initial version of // of the RFC that defined the initial version of
// the module and remove this note // the module and remove this note
} }
// identity statements // identity statements
skipping to change at page 93, line 30 skipping to change at line 4221
} }
<CODE ENDS> <CODE ENDS>
Acknowledgments Acknowledgments
Thanks to Jürgen Schönwälder and Ladislav Lhotka for the discussion Thanks to Jürgen Schönwälder and Ladislav Lhotka for the discussion
and valuable comments. Special thanks to Ladislav Lhotka for sharing and valuable comments. Special thanks to Ladislav Lhotka for sharing
more context that led to the design documented in [RFC9108]. more context that led to the design documented in [RFC9108].
Thanks to Italo Busi, Benoît Claise, Tom Petch, Randy Presuhn, Martin Thanks to Italo Busi, Benoît Claise, Tom Petch, Randy Presuhn, Martin
Björklund, Acee Lindem, Dale R. Worley, Kent Watsen, Jan Lindblad, Björklund, Acee Lindem, Dale R. Worley, Kent Watsen, Jan Lindblad,
Qiufang Ma, Mahesh Jethanandani, Robert Wilton, and Thomas Fossati Qiufang Ma, Mahesh Jethanandani, Robert Wilton, and Thomas Fossati
for the comments. for the comments.
Lou Berger suggested to include more details about IANA Lou Berger suggested to include more details about IANA
considerations. considerations.
Section 4.28 is inspired from [RFC8819]. Section 4.28 is inspired by [RFC8819].
Michal Vaško reported an inconsistency in Sections 4.6.2 and 4.6.4 of Michal Vaško reported an inconsistency in Sections 4.6.2 and 4.6.4 of
[RFC8407]. [RFC8407].
Thanks to Xufeng Liu for reviewing the document, including providing Thanks to Xufeng Liu for reviewing the document, including providing
YANGDOCTORS reviews. YANGDOCTORS reviews.
Italo Busi provided the examples of "case + when" construct. Italo Busi provided the examples of "case + when" construct.
Thanks to Rich Salz and Michael Richardson for the SAAG review. Thanks to Rich Salz and Michael Richardson for the SAAG review.
Kent Watsen contributed text to the security and IANA-maintained Kent Watsen contributed text to the security and IANA-maintained
module templates. module templates.
Special thanks to Amanda Baber for the thoughtful and careful review Special thanks to Amanda Baber for the thoughtful and careful review
of the document. of the document.
Thanks to Qiufang Ma for the careful shepherd review. Thanks to Qiufang Ma for the careful shepherd review.
Thanks to Acee Lindem for triggering the discussion on data model vs. Thanks to Acee Lindem for triggering the discussion on data model
module. versus module.
Thanks to Mahesh Jethanandani for the thoughtful AD review. Thanks to Mahesh Jethanandani for the thoughtful AD review.
Thanks to Christer Holmberg for the genart review, Jean Mahoney for Thanks to Christer Holmberg for the genart review, Jean Mahoney for
the check on RPC implications, Ralf Weber for the dnsdir, Giuseppe the check on RPC implications, Ralf Weber for the dnsdir, Giuseppe
Fioccola for the opsdir review, Joseph Touch for the tsvart review, Fioccola for the opsdir review, Joseph Touch for the tsvart review,
and Yoav Nir for the secdir review. and Yoav Nir for the secdir review.
Thanks Éric Vyncke, Mike Bishop, Roman Danyliw, Orie Steele, Ketan Thanks Éric Vyncke, Mike Bishop, Roman Danyliw, Orie Steele, Ketan
Talaulikar, Deb Cooley, and Gorry Fairhurst for the IESG review. Talaulikar, Deb Cooley, and Gorry Fairhurst for the IESG review.
The author of RFC 8407: Andy Bierman The author of RFC 8407:
YumaWorks
email: andy@yumaworks.com Andy Bierman
YumaWorks
Email: andy@yumaworks.com
Acknowledgments from RFC 8407: The structure and contents of this Acknowledgments from RFC 8407:
document are adapted from "Guidelines for Authors and Reviewers of
MIB Documents" [RFC4181], by C. M. Heard.
The working group thanks Martin Bjorklund, Juergen Schoenwaelder, | The structure and contents of this document are adapted from
Ladislav Lhotka, Jernej Tuljak, Lou Berger, Robert Wilton, Kent | "Guidelines for Authors and Reviewers of MIB Documents" [RFC4181],
Watsen, and William Lupton for their extensive reviews and | by C. M. Heard.
contributions to this document. |
| The working group thanks Martin Bjorklund, Juergen Schoenwaelder,
| Ladislav Lhotka, Jernej Tuljak, Lou Berger, Robert Wilton, Kent
| Watsen, and William Lupton for their extensive reviews and
| contributions to this document.
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
Mohamed Boucadair (editor) Mohamed Boucadair (editor)
Orange Orange
 End of changes. 257 change blocks. 
576 lines changed or deleted 557 lines changed or added

This html diff was produced by rfcdiff 1.48.