< draft-boucadair-netmod-iana-registries-00.txt		draft-boucadair-netmod-iana-registries-01.txt >
	netmod M. Boucadair		netmod M. Boucadair
	Internet-Draft Orange		Internet-Draft Orange
	Updates: 8407 (if approved) 24 March 2022		Updates: 8407 (if approved) 24 March 2022
	Intended status: Standards Track		Intended status: Standards Track
	Expires: 25 September 2022		Expires: 25 September 2022
	Recommendations for Creating IANA-Maintained YANG Modules		Recommendations for Creating IANA-Maintained YANG Modules
	draft-boucadair-netmod-iana-registries-00		draft-boucadair-netmod-iana-registries-01
	Abstract		Abstract
	This document provides a set of guidelines for YANG module authors		This document provides a set of guidelines for YANG module authors
	related to the design of IANA-maintained modules. These guidelines		related to the design of IANA-maintained modules. These guidelines
	are meant to leverage existing IANA registries and use YANG as just		are meant to leverage existing IANA registries and use YANG as just
	another format to present the content of these registries.		another format to present the content of these registries.
	This document updates RFC 8407.		This document updates RFC 8407 by providing additional guidelines for
			IANA-maintained modules. It also relaxes a recommendation related to
			the extensibility for such modules.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 23 ¶
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 4		5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
	7.1. Normative References . . . . . . . . . . . . . . . . . . 4		7.1. Normative References . . . . . . . . . . . . . . . . . . 4
	7.2. Informative References . . . . . . . . . . . . . . . . . 4		7.2. Informative References . . . . . . . . . . . . . . . . . 4
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
	1. Introduction		1. Introduction
	IANA maintains a set of registries that are key for inexorability.		IANA maintains a set of registries that are key for interoperability.
	The content of these registries are usually available using various		The content of these registries are usually available using various
	formats (e.g., plain text, XML). However, there were some confusion		formats (e.g., plain text, XML). However, there were some confusion
	in the past about whether the content of some registries is dependent		in the past about whether the content of some registries is dependent
	on a specific representation format. For example, Section 5 of		on a specific representation format. For example, Section 5 of
	[RFC8892] was published to clarify that MIB and YANG modules are		[RFC8892] was published to clarify that MIB and YANG modules are
	merely additional formats in which the "Interface Types (ifType)" and		merely additional formats in which the "Interface Types (ifType)" and
	"Tunnel Types (tunnelType)" registries are available. The MIB		"Tunnel Types (tunnelType)" registries are available. The MIB
	[RFC2863] and YANG modules [RFC7224][RFC8675] are not separate		[RFC2863] and YANG modules [RFC7224][RFC8675] are not separate
	registries, and the same values are always present in all formats of		registries, and the same values are always present in all formats of
	the same registry.		the same registry.
	skipping to change at page 3, line 37 ¶		skipping to change at page 3, line 35 ¶
	each sub-registry. However, designers MAY consider defining one		each sub-registry. However, designers MAY consider defining one
	single IANA-maintained module that covers all sub-registries if		single IANA-maintained module that covers all sub-registries if
	maintaining that single module is manageable (e.g., very few values		maintaining that single module is manageable (e.g., very few values
	are present or expected to be present for each sub-registry).		are present or expected to be present for each sub-registry).
	An IANA-maintained module may use identities (e.g., [RFC8675]) or		An IANA-maintained module may use identities (e.g., [RFC8675]) or
	typedefs (e.g., [RFC9108]). Such a decision is left to the module		typedefs (e.g., [RFC9108]). Such a decision is left to the module
	designers and should be made based upon specifics related to the		designers and should be made based upon specifics related to the
	intended use of the module. It is RECOMMENDED that the reasoning for		intended use of the module. It is RECOMMENDED that the reasoning for
	the design choice is documented in the companion specification		the design choice is documented in the companion specification
	document. For example, [I-D.ietf-dots-telemetry] define IANA-		document that registers the module. For example,
	maintained module that use typedefs for the following reason:		[I-D.ietf-dots-telemetry] defines an IANA-maintained module that uses
			typedefs for the following reason:
	"The DOTS telemetry module (Section 10.1) uses "enumerations" rather		"The DOTS telemetry module (Section 10.1) uses "enumerations" rather
	than "identities" to define units, samples, and intervals because		than "identities" to define units, samples, and intervals because
	otherwise the namespace identifier "ietf-dots-telemetry" must be		otherwise the namespace identifier "ietf-dots-telemetry" must be
	included when a telemetry attribute is included (e.g., in a		included when a telemetry attribute is included (e.g., in a
	mitigation efficacy update). The use of "identities" is thus		mitigation efficacy update). The use of "identities" is thus
	suboptimal from a message compactness standpoint; one of the key		suboptimal from a message compactness standpoint; one of the key
	requirements for DOTS messages."		requirements for DOTS messages."
	This recommendation takes precedence over the behavior in		For IANA-maintained modules, this recommendation takes precedence
	Section 4.11.1 of [RFC8407] for IANA-maintained modules because the		over the behavior specified in Section 4.11.1 of [RFC8407] because
	extensibility concern is not applicable for such modules.		the extensibility concern is not applicable for such modules.
	Designers of IANA-maintained modules MAY supply the full Initial		Designers of IANA-maintained modules MAY supply the full Initial
	version of the module in the specification document or only a script		version of the module in a specification document that registers the
	to be used by IANA (e.g., XSLT 1.0 stylesheet in Appendix A of		module or only a script to be used by IANA for generating the module
	[RFC9108]).		(e.g., an XSLT 1.0 stylesheet in Appendix A of [RFC9108]).
	4. IANA Considerations		4. IANA Considerations
	This document does not require any IANA action.		This document does not require any IANA action.
	5. Security Considerations		5. Security Considerations
	This document does not introduce new concerns other than those		This document does not introduce new concerns other than those
	already discussed in Section 15 of [RFC8407].		already discussed in Section 15 of [RFC8407].
	6. Acknowledgements		6. Acknowledgements
	This document is triggered by a discusison the author had with Dhruv		This document is triggered by a discussion the author had with Dhruv
	Dhody and Jensen Zhang.		Dhody and Jensen Zhang.
			Thanks to Juergen Schoenwaelder for the comments.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
End of changes. 8 change blocks.
	12 lines changed or deleted		17 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/