rfc9907v1.txt		rfc9907.txt
	skipping to change at line 140 ¶		skipping to change at line 140 ¶
	4.24. Performance Considerations		4.24. Performance Considerations
	4.25. Open Systems Considerations		4.25. Open Systems Considerations
	4.26. Guidelines for Constructs Specific to YANG 1.1		4.26. Guidelines for Constructs Specific to YANG 1.1
	4.26.1. Importing Multiple Revisions		4.26.1. Importing Multiple Revisions
	4.26.2. Using Feature Logic		4.26.2. Using Feature Logic
	4.26.3. "anyxml" versus "anydata"		4.26.3. "anyxml" versus "anydata"
	4.26.4. "action" versus "rpc"		4.26.4. "action" versus "rpc"
	4.27. Updating YANG Modules (Published versus Unpublished)		4.27. Updating YANG Modules (Published versus Unpublished)
	4.28. Defining Standard Tags		4.28. Defining Standard Tags
	4.29. Modeling Abstract Data Structures		4.29. Modeling Abstract Data Structures
	4.30. IANA-Maintained Modules		4.30. IANA-Maintained YANG Modules
	4.30.1. Context		4.30.1. Context
	4.30.2. Guidelines for IANA-Maintained Modules		4.30.2. Guidelines for IANA-Maintained YANG Modules
	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		Defining IANA-Maintained YANG Modules
	5. IANA Considerations		5. IANA Considerations
	5.1. YANG Modules		5.1. YANG Modules
	5.2. Update in YANG Parameters Registry Group		5.2. Update in YANG Parameters Registry Group
	5.3. IANA-Maintained Modules		5.3. IANA-Maintained YANG Modules
	6. Operations and Manageability Considerations		6. Operations and Manageability Considerations
	7. Security Considerations		7. Security Considerations
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	8.2. Informative References		8.2. Informative References
	Appendix A. Module Review Checklist		Appendix A. Module Review Checklist
	Appendix B. Template for IETF Modules		Appendix B. Template for IETF Modules
	Appendix C. Template for IANA-Maintained Modules		Appendix C. Template for IANA-Maintained YANG Modules
	Acknowledgments		Acknowledgments
	Authors' Addresses		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 RESTCONF [RFC8040],		Configuration Protocol (NETCONF) [RFC6241] and RESTCONF [RFC8040],
	requires a modular set of data models that can be reused and extended		requires a modular set of data models that can be reused and extended
	over time.		over time.
	skipping to change at line 191 ¶		skipping to change at line 191 ¶
	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 Stream		models. These guidelines can be used independent of the IETF Stream
	of publication 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
	skipping to change at line 235 ¶		skipping to change at line 235 ¶
	* 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 define YANG extensions such as
			[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
	the conventions described in [RFC8792].		the conventions described in [RFC8792].
	* Added a recommendation about long trees.		* Added a recommendation about long trees.
	skipping to change at line 265 ¶		skipping to change at line 266 ¶
	* 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 guidance for writing IANA Considerations sections to
	to indicate whether or not a module is maintained by IANA.		encourage registration requests to indicate whether or not a
			module is maintained by IANA.
	* Added guidelines for IANA-maintained modules.		* Added guidelines for IANA-maintained YANG modules.
	* Added guidelines about the use of the terms "YANG module" and		* Added guidelines about the use of the terms "YANG module" and
	"YANG data 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
	skipping to change at line 306 ¶		skipping to change at line 308 ¶
	* Fixed an inconsistency in Section 4.6.4 that failed 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 YANG modules.
	* Updated the wiki URLs to use the new structure.		* Updated the wiki URLs to use the new structure.
	* Added anydata to the list of statements with mandatory		* Added anydata to the list of statements with mandatory
	description(s) (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.
	* Softened generic I-D authorship guidance.		* Softened generic I-D authorship guidance.
	2. Terminology and 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 YANG 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 YANG module: A YANG module that is maintained by
	has an IANA registry associated with it (e.g., "iana-tunnel-type"		IANA and has an IANA registry associated with it (e.g., "iana-
	[RFC8675] or "iana-pseudowire-types" [RFC9291]).		tunnel-type" [RFC8675] or "iana-pseudowire-types" [RFC9291]).
	Once an IANA-maintained module is initialized, new values are not		Once an IANA-maintained YANG module is initialized, new values are
	directly added to the module. These values are instead added to		not directly added to the module. These values are instead added
	the companion registry.		to the companion registry.
	IETF module: A YANG module that is published as an RFC from the IETF		IETF module: A YANG module that is published by the IETF and that is
	Stream and that is not maintained by IANA.		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 Series described in Section 2.1 of
	is considered a stable publication.		[RFC2026] 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		example, the Internet-Draft described in Section 2.2 of [RFC2026]
	[RFC2026] is considered an unstable publication that is a work in		is considered an unstable work in progress, subject to change at
	progress and is subject to change at any time.		any time.
	YANG fragment: A set of YANG statements that is 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".
	2.1. NETCONF Terms		2.1. NETCONF Terms
	The following terms are defined in [RFC6241] and are not redefined		The following terms are defined in [RFC6241] and are not redefined
	here:		here:
	* capabilities		* capability
	* client		* client
	* operation		* protocol operation (or simply "operation")
	* server		* server
	2.2. YANG Terms		2.2. YANG Terms
	The following terms are defined in [RFC7950] and are not redefined		The following terms are defined in [RFC7950] and are not redefined
	here:		here:
	* data node		* data node
	skipping to change at line 463 ¶		skipping to change at line 465 ¶
	the body of the document where the overall design is described.		the body of the document where the overall design is described.
	"YANG module" should be used when a specific "*.yang" file is		"YANG module" should be used when a specific "*.yang" file is
	referenced. Likewise, "YANG module" should be used when using terms		referenced. Likewise, "YANG module" should be used when using terms
	related to YANG module specifications (e.g., augmentation or		related to YANG module specifications (e.g., augmentation or
	deviation). However, when extending the concepts embodied in a YANG		deviation). However, when extending the concepts embodied in a YANG
	module, authors should refer to those as an extension to the "YANG		module, authors should refer to those as an extension to the "YANG
	data model".		data model".
	3. General Documentation Guidelines		3. General Documentation Guidelines
	YANG modules under review are likely to be contained in Internet-		YANG modules being considered for publication in an RFC are contained
	Drafts (I-Ds). Guidelines for authoring an I-D can be found at		in Internet-Drafts (I-Ds). Guidelines for authoring an I-D can be
	[ID-Guidelines]. These guidelines are not repeated here.		found at [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)
	* A Definitions section (Section 3.6)		* A Definitions section(s) (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 3.7)		* Security Considerations (Section 3.7)
	* IANA Considerations (Section 3.8)		* IANA Considerations (Section 3.8)
	* References (Section 3.9)		* References (Section 3.9)
	skipping to change at line 566 ¶		skipping to change at line 568 ¶
	structure. Guidelines on tree diagrams can be found in Section 3 of		structure. Guidelines on tree diagrams can be found in Section 3 of
	[RFC8340]. Tree diagrams longer than one page SHOULD be included in		[RFC8340]. Tree diagrams longer than one page SHOULD be included in
	an appendix, i.e., not in the main body of the document.		an appendix, i.e., not in the main body of the document.
	If YANG tree diagrams are used, then an informative reference to the		If YANG tree diagrams are used, then an informative reference to the
	YANG tree diagrams specification MUST be included in the document.		YANG tree diagrams specification MUST be included in the document.
	Refer to Section 2.2 of [RFC8349] for an example of such a reference.		Refer to Section 2.2 of [RFC8349] for an example of such a reference.
	3.5. Narrative Sections		3.5. Narrative Sections
	The narrative part MUST include an overview section that describes		The narrative sections MUST include an overview section that
	the scope and field of application of the data model(s) defined by		describes the scope and field of application of the data model(s)
	the specification and that specifies the relationship (if any) of		defined by the specification and that specifies the relationship (if
	these data models to other standards, particularly to standards		any) of these data models to other standards, particularly to
	containing other YANG data models. The narrative part SHOULD include		standards containing other YANG data models. The narrative part
	one or more sections to briefly describe the structure of the data		SHOULD include one or more sections to briefly describe the structure
	models defined in the specification.		of the data models defined in the specification.
	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 [RFC9911]) or is 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 includes a temporary non-NMDA		Architecture (NMDA) exceptions or includes a temporary non-NMDA
	module [RFC8342], then the Introduction section SHOULD mention this		module [RFC8342], then the Introduction section SHOULD mention this
	fact with the reasoning that motivated that design. Refer to		fact with the reasoning that motivated that design. Refer to
	Section 4.23 for more NMDA-related guidance. Specifically,		Section 4.23 for more NMDA-related guidance. Specifically,
	skipping to change at line 643 ¶		skipping to change at line 645 ¶
	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		A non-comprehensive list of device models is provided in
	Appendix A.4.2 of [RFC8969].		Appendix A.4.4 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.
	skipping to change at line 669 ¶		skipping to change at line 671 ¶
	affected by these guidelines.		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 key words from [RFC2119] and [RFC8174].
	[RFC2119] and [RFC8174].
	Consistent indentation and formatting (e.g., folding) SHOULD be used		Consistent indentation and formatting (e.g., folding) SHOULD be used
	in all YANG statements within a module.		in all YANG statements within a module.
	See Section 4 for guidelines on YANG usage.		See Section 4 for guidelines on YANG usage.
	3.7. Security Considerations Section		3.7. Security Considerations Section
	Each specification that defines one or more modules MUST contain a		Each specification that defines one or more modules MUST contain a
	section that discusses security considerations relevant to those		section that discusses security considerations relevant to those
	skipping to change at line 718 ¶		skipping to change at line 719 ¶
	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.1
	of [RFC9907].		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,
	NETCONF [RFC6241] and RESTCONF [RFC8040]. These YANG-based		such as Network Configuration Protocol (NETCONF) [RFC6241]
	management protocols (1) have to use a secure transport layer		and RESTCONF [RFC8040]. These YANG-based management protocols
	(e.g., SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) have		(1) have to use a secure transport layer (e.g., Secure Shell (SSH)
	to use mutual authentication.		[RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) have 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.
			Note: RFC 8341 (or a future RFC that replaces it) MUST be listed
			as a normative reference.
			By default, RFC 4252, RFC 6241, RFC 8040, RFC 8446, RFC 9000, 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.
	-- Writable nodes section:		-- Writable nodes section:
	--		--
	-- If the data model contains any writable data nodes (those are all		-- If the data model contains any writable data nodes (those are all
	-- the "config true" nodes), then include the following text:		-- the "config true" nodes), then include the following text:
	There are a number of data nodes defined in this YANG module that are		There are a number of data nodes defined in this YANG module that are
	writable/creatable/deletable (i.e., "config true", which is the		writable/creatable/deletable (i.e., "config true", which is the
	default). All writable data nodes are likely to be sensitive or		default). All writable data nodes are likely to be sensitive or
	vulnerable in some network environments. Write		vulnerable in some network environments. Write
	operations (e.g., edit-config) and delete operations to these data		operations (e.g., edit-config) and delete operations to these data
	skipping to change at line 773 ¶		skipping to change at line 783 ¶
	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) that are particularly sensitive or vulnerable
	-- if they might reveal customer information or violate personal		-- (e.g., if they might reveal customer information or violate
	-- privacy laws). Typically, particularly sensitive readable		-- personal privacy laws). Typically, particularly sensitive
	-- data nodes are ones that are protected by a		-- readable 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
	-- include the following text:		-- include the following text:
	skipping to change at line 806 ¶		skipping to change at line 816 ¶
	-- here, along with an explanation of the associated specific		-- here, along with an explanation of the associated specific
	-- sensitivity or vulnerability concerns.		-- sensitivity or vulnerability concerns.
	--		--
	-- Otherwise, state:		-- Otherwise, state:
	-- "There are no particularly sensitive RPC or action operations."		-- "There are no particularly sensitive RPC or action operations."
	-- 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 as a
	-- the specific sensitivity or vulnerability of reused nodes.		-- reminder of 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
	skipping to change at line 835 ¶		skipping to change at line 846 ¶
	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>		<CODE ENDS>
	| Note: [RFC8341] (or a future RFC that replaces it) MUST be
	| listed as a normative reference.
	|
	| 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 or not the		"YANG Module Names" registry should indicate whether or not the
	module is IANA-maintained. 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 YANG
	(including instructions to maintain them) are provided in		modules (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
	skipping to change at line 906 ¶		skipping to change at line 908 ¶
	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] [RFC9890] 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.
	For every normative reference statement that appears in a module		For every normative reference statement that appears in a module
	contained in the specification that identifies a separate document, a		contained in the specification that identifies a separate document, a
	corresponding normative reference to that document SHOULD appear in		corresponding normative reference to that document SHOULD appear in
	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.
			Except the "import" and "revision" statements, note that it is
			acceptable to reference RFCs with their labels and without expanding
			their titles. An example of such use is as follows:
			leaf site-of-origin {
			type rt-types:route-origin;
			description
			"The Site of Origin attribute is encoded as a Route Origin
			Extended Community. It is meant to uniquely identify the
			set of routes learned from a site via a particular AC and
			is used to prevent routing loops.";
			reference
			"RFC 4364, Section 7";
			}
			leaf ipv6-site-of-origin {
			type rt-types:ipv6-route-origin;
			description
			"The IPv6 Site of Origin attribute is encoded as an IPv6
			Route Origin Extended Community. It is meant to uniquely
			identify the set of routes learned from a site.";
			reference
			"RFC 5701";
			}
			}
	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.
	skipping to change at line 990 ¶		skipping to change at line 1017 ¶
	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: <https://github.com/xym-tool/		extract YANG modules from a document: <https://github.com/xym-tool/
	xym>.		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 that are meant to illustrate a valid
	Refer to Section 3.10 for tools that validate YANG modules and		data instance MUST be validated (Section 3.10). Refer to
	examples. If IP addresses/prefixes are used, then a mix of either		Section 3.10 for tools that validate YANG modules and examples. If
	IPv4 and IPv6 addresses/prefixes or IPv6 addresses/prefixes		IP addresses/prefixes are used, then a mix of either IPv4 and IPv6
	exclusively SHOULD be used in the examples.		addresses/prefixes or IPv6 addresses/prefixes exclusively SHOULD be
			used in the examples.
	For some types (IP addresses, domain names, etc.), the IETF has		For some types (IP addresses, domain names, etc.), the IETF has
	reserved values for documentation use. Authors SHOULD use these		reserved values for documentation use. Authors SHOULD use these
	reserved values in the usage examples if these types are used.		reserved values in the usage examples if these types are used.
	Examples of reserved values are listed below:		Examples of reserved values are listed below:
	* IPv4 and IPv6 addresses/prefixes reserved for documentation are		* IPv4 and IPv6 addresses/prefixes reserved for documentation are
	defined in [RFC5737], [RFC3849], and [RFC9637].		defined in [RFC5737], [RFC3849], and [RFC9637].
	* The Enterprise Number 32473 reserved for documentation use is		* The Enterprise Number 32473 reserved for documentation use is
	skipping to change at line 1613 ¶		skipping to change at line 1641 ¶
	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
	within an import statement.		within an import statement.
	import ietf-yang-types {		import ietf-yang-types {
	prefix yang;		prefix yang;
	reference "RFC 6991: Common YANG Data Types";		reference "RFC 9911: Common YANG Data Types";
	}		}
	If submodules are used, then the document containing the main module		If submodules are used, then the document containing the main module
	MUST be updated so that the main module revision date is equal to or		MUST be updated so that the main module revision date is equal to or
	more recent than the revision date of any submodule that is (directly		more recent than the revision date of any submodule that is (directly
	or indirectly) included by the main module.		or indirectly) included by the main module.
	Definitions for future use SHOULD NOT be specified in a module. Do		Definitions for future use SHOULD NOT be specified in a module. Do
	not specify placeholder objects like the "reserved" example below:		not specify placeholder objects like the "reserved" example below:
	skipping to change at line 1641 ¶		skipping to change at line 1669 ¶
	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 are not limited to):		to write the document. Exceptions include (but are not limited to):
	example modules, IANA-maintained modules, or modules contained in AD-		example modules, IANA-maintained YANG modules, or modules contained
	sponsored documents. For other standards organizations, a similar		in AD-sponsored documents. For other standards organizations, a
	approach is also suggested.		similar 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
	skipping to change at line 1703 ¶		skipping to change at line 1731 ¶
	revision.		revision.
	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
	"RFC 6991: Common YANG Data Types";		"RFC 9911: Common YANG Data Types";
	}		}
	revision 2010-09-24 {		revision 2010-09-24 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC 6021: Common YANG Data Types";		"RFC 6021: Common YANG Data Types";
	}		}
	For an unpublished module, a complete history of each unpublished		For an unpublished module, a complete history of each unpublished
	skipping to change at line 1727 ¶		skipping to change at line 1755 ¶
	module. A new revision date is not required unless the module		module. A new revision date is not required unless the module
	contents have changed. If the module contents have changed, then the		contents have changed. If the module contents have changed, then the
	revision date of that new module version MUST be updated to a date		revision date of that new module version MUST be updated to a date
	later than that of the previous version.		later than that of the previous version.
	The following example shows the revision statements for an		The following example shows the revision statements for an
	unpublished update to a published YANG module. The latest revision		unpublished update to a published YANG module. The latest revision
	statement of the unpublished module summarizes the changes compared		statement of the unpublished module summarizes the changes compared
	to the previous revision.		to the previous revision.
	revision 2023-01-23 {		revision 2025-12-22 {
	description		description
	"This revision adds the following new data types:		"This revision adds the following new data types:
	- yang:date-with-zone-offset		- yang:date
	- yang:date-no-zone		- yang:date-no-zone
	- yang:time-with-zone-offset		- yang:time
	- yang:time-no-zone		- yang:time-no-zone
	- yang:hours32		- yang:hours32
	- yang:minutes32		- yang:minutes32
	- yang:seconds32		- yang:seconds32
	- 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
	Several pattern statements have been improved.";		1.1 and types representing time support the representation
			of leap seconds. The representation of time zone offsets
			has been aligned with RFC 9557. Several description and
			pattern statements have been improved.";
	reference		reference
	"RFC 6991: Common YANG Data Types";		"RFC 9911: 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
	"RFC 6991: Common YANG Data Types";		"RFC 9911: Common YANG Data Types";
	}		}
	revision 2010-09-24 {		revision 2010-09-24 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC 6021: Common YANG Data Types";		"RFC 6021: Common YANG Data Types";
	}		}
	4.9. Namespace Assignments		4.9. Namespace Assignments
	skipping to change at line 1922 ¶		skipping to change at line 1953 ¶
	4.11.2. Patterns and Ranges		4.11.2. Patterns and Ranges
	For string data types, if a machine-readable pattern can be defined		For string data types, if a machine-readable pattern can be defined
	for the desired semantics, then one or more pattern statements SHOULD		for the desired semantics, then one or more pattern statements SHOULD
	be present. A single-quoted string SHOULD be used to specify the		be present. A single-quoted string SHOULD be used to specify the
	pattern, since a double-quoted string can modify the content. If the		pattern, since a double-quoted string can modify the content. If the
	patterns used in a type definition have known limitations such as		patterns used in a type definition have known limitations such as
	false negative or false positive matches, then these limitations		false negative or false positive matches, then these limitations
	SHOULD be documented within the typedef or data definition.		SHOULD be documented within the typedef or data definition.
	The following typedef from [RFC6991] demonstrates the proper use of		The following typedef from [RFC9911] demonstrates the proper use of
	the "pattern" statement:		the "pattern" statement:
	typedef ipv6-address-no-zone {		typedef ipv6-address-no-zone {
	type inet:ipv6-address {		type inet:ipv6-address {
	pattern '[0-9a-fA-F:\.]*';		pattern '[0-9a-fA-F:\.]*';
	}		}
	...		...
	}		}
	For string data types, if the length of the string is required to be		For string data types, if the length of the string is required to be
	bounded in all implementations, then a length statement MUST be		bounded in all implementations, then a length statement MUST be
	present.		present.
	The following typedef from [RFC6991] demonstrates the proper use of		The following typedef from [RFC9911] demonstrates the proper use of
	the "length" statement:		the "length" statement:
	typedef yang-identifier {		typedef yang-identifier {
	type string {		type string {
	length "1..max";		length "1..max";
	pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';		pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
	pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*';		pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*';
	}		}
	...		...
	}		}
	For numeric data types, if the values allowed by the intended		For numeric data types, if the values allowed by the intended
	semantics are different than those allowed by the unbounded intrinsic		semantics are different than those allowed by the unbounded intrinsic
	data type (e.g., "int32"), then a range statement SHOULD be present.		data type (e.g., "int32"), then a range statement SHOULD be present.
	The following typedef from [RFC6991] demonstrates the proper use of		The following typedef from [RFC9911] demonstrates the proper use of
	the "range" statement:		the "range" statement:
	typedef dscp {		typedef dscp {
	type uint8 {		type uint8 {
	range "0..63";		range "0..63";
	}		}
	...		...
	}		}
	4.11.3. Enumerations and Bits		4.11.3. Enumerations and Bits
	skipping to change at line 2095 ¶		skipping to change at line 2126 ¶
	Correct:		Correct:
	leaf flag2 {		leaf flag2 {
	type boolean;		type boolean;
	default false;		default false;
	}		}
	4.12. Reusable Type Definitions		4.12. Reusable Type Definitions
	If an appropriate derived type exists in any standard module, such as		If an appropriate derived type exists in any standard module, such as
	[RFC6991], then it SHOULD be used instead of defining a new derived		[RFC9911], then it SHOULD be used instead of defining a new derived
	type.		type.
	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,
	skipping to change at line 2921 ¶		skipping to change at line 2952 ¶
	4.25. Open Systems Considerations		4.25. Open Systems Considerations
	Only the modules imported by a particular module can be assumed to be		Only the modules imported by a particular module can be assumed to be
	present in an implementation. An open system MAY include any		present in an implementation. An open system MAY include any
	combination of YANG modules.		combination of YANG modules.
	4.26. Guidelines for Constructs Specific to YANG 1.1		4.26. Guidelines for Constructs Specific to YANG 1.1
	The set of guidelines for YANG 1.1 will grow as operational		The set of guidelines for YANG 1.1 will grow as operational
	experience is gained with the new language features. This section		experience is gained with the new language features. This section
	contains an initial set of guidelines for new YANG 1.1 language		contains an initial set of guidelines for YANG 1.1 language features.
	features.
	4.26.1. Importing Multiple Revisions		4.26.1. Importing Multiple Revisions
	Standard modules SHOULD NOT import multiple revisions of the same		Standard modules SHOULD NOT import multiple revisions of the same
	module into a module. This MAY be done if independent definitions		module into a module. This MAY be done if independent definitions
	(e.g., enumeration typedefs) from specific revisions are needed in		(e.g., enumeration typedefs) from specific revisions are needed in
	the importing module.		the importing module.
	4.26.2. Using Feature Logic		4.26.2. Using Feature Logic
	skipping to change at line 3017 ¶		skipping to change at line 3047 ¶
	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, an RFC is used for published		be unstable. For example, in the IETF, an RFC is used for published
	work, and an 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 the time of module design, at		Tags may be defined and associated at design time, at implementation
	the time of implementation, or via user administrative control.		time, or via user administrative control. Design-time tags are
	Design-time tags are indicated using the module-tag extension		indicated using the module-tag extension statement.
	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 line 3055 ¶		skipping to change at line 3084 ¶
	(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]. Examples of modules that rely upon		extension statement [RFC8040]. Examples of modules that rely upon
	the "structure" extension statement from [RFC8791] can be found in		the "structure" extension statement from [RFC8791] can be found in
	[RFC9132] or [RFC9195].		[RFC9132] or [RFC9195].
	Abstract data structures can be augmented using the "augment-		Abstract data structures can be augmented using the "augment-
	structure" statement [RFC8791]. Examples of modules that augment		structure" statement [RFC8791]. Examples of modules that augment
	abstract data structures can be found in [RFC9244] and [RFC9362].		abstract data structures can be found in [RFC9244] and [RFC9362].
	4.30. IANA-Maintained Modules		4.30. IANA-Maintained YANG 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 is usually available using various		The content of these registries is usually available using various
	formats (e.g., plain text or XML). However, there was 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
	skipping to change at line 3081 ¶		skipping to change at line 3110 ¶
	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 the ability to support new values		For the sake of consistency and the ability to support new values
	while maintaining IANA registries as the unique authoritative source		while maintaining IANA registries as the unique authoritative source
	of 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.		YANG 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 YANG 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 YANG Modules
	When designing a YANG module for a functionality governed by a		When designing a YANG module for a functionality governed by a
	protocol for which IANA maintains a registry, it is RECOMMENDED to		protocol for which IANA maintains a registry, it is RECOMMENDED to
	specify an IANA-maintained module that echoes the content of that		specify an IANA-maintained YANG module that echoes the content of
	registry. This is superior to including that content in an IETF-		that registry. This is superior to including that content in an
	maintained module.		IETF-maintained module.
	When one or multiple registries are available under the same registry		When one or multiple registries are available under the same registry
	group, it is RECOMMENDED to define an IANA-maintained module for each		group, it is RECOMMENDED to define an IANA-maintained YANG module for
	registry. However, module designers MAY consider defining one single		each registry. However, module designers MAY consider defining one
	IANA-maintained module that covers all registries if maintaining that		single IANA-maintained YANG module that covers all registries if
	single module is manageable (e.g., very few values are present or		maintaining that single module is manageable (e.g., very few values
	expected to be present for each registry). An example of such a		are present or expected to be present for each registry). An example
	module is documented in Section 5.2 of [RFC9132].		of such a module is documented in Section 5.2 of [RFC9132].
	An IANA-maintained module may use the "identityref" data type (e.g.,		An IANA-maintained YANG module may use the "identityref" data type
	[RFC8675]) or an enumeration data type (e.g., [RFC9108]). See		approach (e.g., [RFC8675]) or an enumeration data type approach
	Section 4.11.1 for a guidance on which data type to use. The		(e.g., [RFC9108]). See Section 4.11.1 for a guidance on which data
	decision about which type to use should be made based upon specifics		type to use. The decision about which type to use should be made
	related to the intended use of the IANA-maintained module. For		based upon specifics related to the intended use of the IANA-
	example, identities are useful if the registry entries are organized		maintained YANG module. For example, identities are useful if the
	hierarchically, possibly including multiple inheritances. The		registry entries are organized hierarchically, possibly including
	reasoning for the design choice MUST be documented in the companion		multiple inheritances. The reasoning for the design choice MUST be
	specification that registers an IANA-maintained module. For example,		documented in the companion specification that registers an IANA-
	[RFC9244] defines an IANA-maintained module that uses enumerations		maintained YANG module. For example, [RFC9244] defines an IANA-
	for the following reason:		maintained YANG module that uses enumerations for the following
			reason:
	| The DOTS telemetry module (Section 11.1) uses "enumerations"		| The DOTS telemetry module (Section 11.1) uses "enumerations"
	| rather than "identities" to define units, samples, and intervals		| rather than "identities" to define units, samples, and intervals
	| 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 YANG modules MAY supply the initial full
	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 Extensible Stylesheet Language Transformations		the module (e.g., an Extensible Stylesheet Language Transformations
	(XSLT) stylesheet as in Appendix A of [RFC9108] or a Python script as		(XSLT) stylesheet as in Appendix A of [RFC9108] or a Python script as
	in [RFC9645]). For both cases, the document that defines an IANA-		in [RFC9645]). For both cases, the document that defines an IANA-
	maintained module MUST include a note indicating that the document is		maintained YANG module MUST include a note indicating that the
	only documenting the initial version of the module and that the		document is only documenting the initial version of the module and
	authoritative version is to be retrieved from the IANA registry.		that the authoritative version is to be retrieved from the IANA
	Also, the IANA-maintained module MUST include the following note		registry. Also, the IANA-maintained module MUST include the
	indicating the RFC that registered the initial version of the IANA-		following note indicating the RFC that registered the initial version
	maintained module:		of the IANA-maintained YANG 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 has to include an		Draft that defines an IANA-maintained YANG 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		Internet-Drafts 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 YANG modules that are published
	RFCs may be misused despite the appropriate language to refer to the		in RFCs may be misused despite the appropriate language to refer to
	IANA registry to retrieve the up-to-date module. This is problematic		the IANA registry to retrieve the up-to-date module. This is
	for interoperability, e.g., when values are deprecated or are		problematic for interoperability, e.g., when values are deprecated or
	associated with a new meaning.		are 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		| used to generate up-to-date revisions of an IANA-maintained
	| module based upon the XML representation of an IANA registry.		| YANG 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 YANG module is imported by another module, a
	normative reference with the IANA URL from which 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 YANG module SHOULD be included. Although not
	referencing the RFC that defines the initial version of the IANA		encouraged, referencing the RFC that defines the initial version of
	module is acceptable in specific cases (e.g., the imported version is		the IANA module is acceptable in specific cases (e.g., the imported
	specifically the initial version, the RFC includes useful description		version is specifically the initial version, the RFC includes useful
	about the usage of the module).		description about the usage of the module).
	Examples of IANA URLs from which to retrieve the latest version of an		Examples of IANA URLs from which to retrieve the latest version of an
	IANA-maintained module are as follows: [IANA_BGP-L2_URL],		IANA-maintained YANG module are as follows:
	[IANA_PW-Types_URL], and [IANA_BFD_URL]. "IANA_FOO_URL" is used in
	the following to refer to such URLs. These URLs are expected to be
	sufficiently permanent and stable. Whenever referencing a specific
	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
	in the following to refer to such URLs.
	A template for IANA-maintained modules is provided in Appendix C.		* https://www.iana.org/assignments/iana-bgp-l2-encaps,
			* https://www.iana.org/assignments/iana-pseudowire-types, and
			* https://www.iana.org/assignments/iana-bfd-types.
			"IANA_FOO_URL" is used in the following to refer to such URLs. These
			URLs are expected to be sufficiently permanent and stable.
			Whenever referencing a specific version of an IANA-maintained YANG
			module is needed, then URLs such as the following are used:
			* https://www.iana.org/assignments/iana-bgp-l2-encaps
			"IANA_FOO_URL_With_REV" is used in the following to refer to such
			URLs.
			A template for IANA-maintained YANG 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 YANG 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		YANG 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 YANG module that are triggered by a change to the
	registry. Concretely, the IANA Considerations section SHALL at least		authoritative registry. Concretely, the IANA Considerations section
	provide the following information:		SHALL at least 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 YANG module that new values
	not be directly added to the module. These values should be added		must not be directly added to the module. These values should be
	to an authoritative IANA registry.		added 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 YANG module. That is, any
	the registry must be accompanied by an update to the corresponding		changes to the registry must be accompanied by an update to the
	IANA-maintained module.		corresponding IANA-maintained YANG 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 YANG module to
	changes to an authoritative IANA registry. Typically, these		reflect changes to an authoritative IANA registry. Typically,
	details have to include the procedure to create a new "identity"		these details have to include the procedure to create a new
	statement name and substatements ("base", "status", "description",		"identity" statement name and substatements ("base", "status",
	and "reference") or a new "enum" statement and substatements		"description", and "reference") or a new "enum" statement and
	("value", "status", "description", and "reference").		substatements ("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., not use a digit) the number
	used as an identifier. IANA should be provided with		when used as an identifier. IANA should be provided with
	instructions to perform such a 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 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 YANG module for
	patterns. If all else fails, IANA should seek advice from		similar patterns. If all else fails, IANA should seek advice
	relevant registry experts (e.g., designated experts for a		from relevant registry experts (e.g., designated experts for a
	registry using the Expert Review policy (Section 4.5 of		registry using the Expert Review policy (Section 4.5 of
	[RFC8126]) 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 YANG 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 YANG 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 YANG
	module.		module.
	* An instruction about how to generate the "revision" statement.		* An instruction about how to generate the "revision" statement.
	A template for the IANA Considerations is provided in		A template for the IANA Considerations is provided in
	Section 4.30.3.1 for IANA-maintained modules with identities and		Section 4.30.3.1 for IANA-maintained YANG modules with identities and
	Section 4.30.3.2 for IANA-maintained modules with enumerations.		Section 4.30.3.2 for IANA-maintained YANG modules with enumerations.
	Authors may modify the template to reflect specifics of their modules		Authors may modify the template to reflect specifics of their modules
	(e.g., multiple registries can be listed for a single IANA-maintained		(e.g., multiple registries can be listed for a single IANA-maintained
	module, no explicit description (or name) field is listed under the		YANG module, no explicit description (or name) field is listed under
	authoritative IANA registry, or the name does not comply with YANG		the authoritative IANA registry, or the name does not comply with
	naming conventions (Section 4.3.1)).		YANG naming conventions (Section 4.3.1)).
	An example of "revision" statements that are generated following the		An example of "revision" statements that are generated following the
	guidance in Section 4.30.3.1 is provided below:		guidance in Section 4.30.3.1 is provided below:
	revision 2023-11-27 {		revision 2023-11-27 {
	description		description
	"Registered RR Type RESINFO 261.";		"Registered RR Type RESINFO 261.";
	reference		reference
	"https://www.iana.org/assignments/yang-parameters/"		"https://www.iana.org/assignments/yang-parameters/"
	+ "iana-dns-class-rr-type@2023-11-27.yang";		+ "iana-dns-class-rr-type@2023-11-27.yang";
	skipping to change at line 3333 ¶		skipping to change at line 3376 ¶
	"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 line 3360 ¶		skipping to change at line 3403 ¶
	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 templates in the following subsections are to be considered in		The templates in the following subsections are to be considered in
	addition to the 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 YANG 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:
	skipping to change at line 3450 ¶		skipping to change at line 3493 ¶
	-- 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 YANG 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:
	skipping to change at line 3553 ¶		skipping to change at line 3596 ¶
	XML: N/A; the requested URI is an XML namespace.		XML: N/A; the requested URI is an XML namespace.
	IANA has registered the following URI in the "ns" registry within the		IANA has registered the following URI in the "ns" registry within the
	"IETF XML Registry" 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.
	IANA has registered the following YANG modules in the "YANG Module		IANA has registered the following YANG modules in the "YANG Module
	Names" registry [RFC6020] within the "YANG Parameters" registry		Names" registry [RFC6020] [RFC9890] within the "YANG Parameters"
	group.		registry 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 9907		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 9907		Reference: RFC 9907
	5.2. Update in YANG Parameters Registry Group		5.2. Update in YANG Parameters Registry Group
	For the references of the "YANG Module Names" registry under the		For the references of the "YANG Module Names" registry under the
	"YANG Parameters" registry group, IANA has updated [RFC8407] to this		"YANG Parameters" registry group, IANA has updated [RFC8407] 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 YANG 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 YANG modules. These considerations
	both the creation and maintenance of an IANA-mainatined module. In		cover both the creation and maintenance of an IANA-mainatined module.
	particular, the following should be noted:		In particular, the following should be noted:
	* When an underlying registration is deprecated or obsoleted, a		* When an underlying registration is deprecated or obsoleted, a
	corresponding "status" substatement should be added to the		corresponding "status" substatement should be added to the
	identity or enumeration statement.		identity or enumeration statement.
	* The "reference" substatement should point specifically to the		* The "reference" substatement should point specifically to the
	published module (i.e., IANA_FOO_URL_With_REV). When the		published module (i.e., IANA_FOO_URL_With_REV). When the
	registration is triggered by an RFC, that RFC must also be		registration is triggered by an RFC, that RFC must also be
	included in the "reference" substatement. It may also point to an		included in the "reference" substatement. It may also point to an
	authoritative event triggering the update to the YANG module. In		authoritative event triggering the update to the YANG module. In
	skipping to change at line 3695 ¶		skipping to change at line 3738 ¶
	[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/info/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/info/rfc8819>.		<https://www.rfc-editor.org/info/rfc8819>.
			[RFC9890] Bierman, A., Boucadair, M., Ed., and Q. Wu, "An Update to
			YANG Module Names Registration", RFC 9890,
			DOI 10.17487/RFC9890, October 2025,
			<https://www.rfc-editor.org/info/rfc9890>.
	[W3C.REC-xpath]		[W3C.REC-xpath]
	Clark, J., Ed. and S. DeRose, Ed., "XML Path Language		Clark, J., Ed. and S. DeRose, Ed., "XML Path Language
	(XPath) Version 1.0", W3C Recommendation, 16 November		(XPath) Version 1.0", W3C Recommendation, 16 November
	1999, <https://www.w3.org/TR/1999/REC-xpath-19991116>.		1999, <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,		[Err5693] RFC Errata, Erratum ID 5693, RFC 8407,
	<https://www.rfc-editor.org/errata/eid5693>.		<https://www.rfc-editor.org/errata/eid5693>.
	skipping to change at line 3729 ¶		skipping to change at line 3777 ¶
	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]
	IANA, "YANG Parameters",		IANA, "YANG Parameters",
	<https://www.iana.org/assignments/yang-parameters>.		<https://www.iana.org/assignments/yang-parameters>.
	[IANA_BFD_URL]
	IANA, "iana-bfd-types YANG Module",
	<https://www.iana.org/assignments/iana-bfd-types>.
	[IANA_BGP-L2_URL]
	IANA, "iana-bgp-l2-encaps YANG Module",
	<https://www.iana.org/assignments/iana-bgp-l2-encaps>.
	[IANA_BGP-L2_URL-Revision]
	IANA, "iana-bfd-types@2021-10-21.yang",
	<https://www.iana.org/assignments/yang-parameters/iana-
	bfd-types@2021-10-21.yang>.
	[IANA_PW-Types_URL]
	IANA, "iana-pseudowire-types YANG Module",
	<https://www.iana.org/assignments/iana-pseudowire-types>.
	[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>.		<https://www.iana.org/assignments/iana-tunnel-type>.
	[ID-Guidelines]		[ID-Guidelines]
	IETF, "Content guidelines overview",		IETF, "Content guidelines overview",
	<https://authors.ietf.org/en/content-guidelines-overview>.		<https://authors.ietf.org/en/content-guidelines-overview>.
	[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,
	skipping to change at line 3800 ¶		skipping to change at line 3831 ¶
	[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/info/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/info/rfc5737>.		<https://www.rfc-editor.org/info/rfc5737>.
	[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
	RFC 6991, DOI 10.17487/RFC6991, July 2013,
	<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/info/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/info/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,
	skipping to change at line 3934 ¶		skipping to change at line 3961 ¶
	<https://www.rfc-editor.org/info/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/info/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/info/rfc9645>.		<https://www.rfc-editor.org/info/rfc9645>.
			[RFC9911] Schönwälder, J., Ed., "Common YANG Data Types", RFC 9911,
			DOI 10.17487/RFC9911, December 2025,
			<https://www.rfc-editor.org/info/rfc9911>.
	[Style] "IANA YANG", commit 3a6cb69, December 2021,		[Style] "IANA YANG", commit 3a6cb69, December 2021,
	<https://github.com/llhotka/iana-yang>.		<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/		sections (see <https://authors.ietf.org/required-content>).
	guidelines.html>), including the appropriate statement to permit
	publication as an RFC, and that the I-D boilerplate does not
	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
	skipping to change at line 4048 ¶		skipping to change at line 4076 ¶
	// import ietf-yang-types { prefix yang; }		// import ietf-yang-types { prefix yang; }
	// import ietf-inet-types { prefix inet; }		// import ietf-inet-types { prefix inet; }
	// identify the IETF working group if applicable		// identify the IETF working group if applicable
	organization		organization
	"IETF your-wg-name (Expanded WG Name) Working Group";		"IETF your-wg-name (Expanded WG Name) Working Group";
	// update this contact statement with your info		// update this contact statement with your info
	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: YOUR-WG-NAME <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
	skipping to change at line 4079 ¶		skipping to change at line 4107 ¶
	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 with actual RFC number and remove
	// 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)
			// RFC Ed.: replace XXXX with actual RFC number and remove
			// this note
	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		// Authors: 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 XXXX: <Replace With Document Title>";		"RFC IIII: <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
	// notification statements		// notification statements
	// DO NOT put deviation statements in a published module		// DO NOT put deviation statements in a published module
	}		}
	<CODE ENDS>		<CODE ENDS>
	Appendix C. Template for IANA-Maintained Modules		Appendix C. Template for IANA-Maintained YANG Modules
	<CODE BEGINS> file "iana-template@2023-12-08.yang"		<CODE BEGINS> file "iana-template@2023-12-08.yang"
	module iana-template {		module iana-template {
	yang-version 1.1;		yang-version 1.1;
	// replace this string with a unique namespace URN value		// replace this string with a unique namespace URN value
	namespace "urn:ietf:params:xml:ns:yang:iana-template";		namespace "urn:ietf:params:xml:ns:yang:iana-template";
	// replace with the assigned prefix		// replace with the assigned prefix
	skipping to change at line 4140 ¶		skipping to change at line 4168 ¶
	organization		organization
	"Internet Assigned Numbers Authority (IANA)";		"Internet Assigned Numbers Authority (IANA)";
	contact		contact
	"Internet Assigned Numbers Authority		"Internet Assigned Numbers Authority
	ICANN		ICANN
	12025 Waterfront Drive, Suite 300		12025 Waterfront Drive, Suite 300
	Los Angeles, CA 90094		Los Angeles, CA 90094
	Tel: +1 424 254 5300		Tel: +1 310 301 5800
	<mailto:iana@iana.org>";		<mailto:iana@iana.org>";
	description		description
	"This module defines a template for IANA-maintained modules.		"This module defines a template for IANA-maintained 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
	skipping to change at line 4240 ¶		skipping to change at line 4268 ¶
	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 YANG
	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		Thanks to Acee Lindem for triggering the discussion on data model
	versus module.		versus module.
End of changes. 100 change blocks.
	250 lines changed or deleted		278 lines changed or added
This html diff was produced by rfcdiff 1.48.