Diff: rfc9911v1.txt - rfc9911.txt

	rfc9911v1.txt		rfc9911.txt

	skipping to change at line 13 ¶		skipping to change at line 13 ¶
	Request for Comments: 9911 Constructor University		Request for Comments: 9911 Constructor University
	Obsoletes: 6991 December 2025		Obsoletes: 6991 December 2025
	Category: Standards Track		Category: Standards Track
	ISSN: 2070-1721		ISSN: 2070-1721

	Common YANG Data Types		Common YANG Data Types

	Abstract		Abstract

	This document defines a collection of common data types to be used		This document defines a collection of common data types to be used

	with the YANG data modeling language. This version of the document		with the YANG data modeling language. This version includes several
	adds several new type definitions and obsoletes RFC 6991.		new type definitions and obsoletes RFC 6991.

	Status of This Memo		Status of This Memo

	This is an Internet Standards Track document.		This is an Internet Standards Track document.

	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.		Internet Standards is available in Section 2 of RFC 7841.

	skipping to change at line 88 ¶		skipping to change at line 88 ¶

	This document defines a collection of common data types. The		This document defines a collection of common data types. The
	definitions are organized into two YANG modules:		definitions are organized into two YANG modules:

	* The "ietf-yang-types" module defines generally useful data types		* The "ietf-yang-types" module defines generally useful data types
	such as types for counters and gauges, types related to date and		such as types for counters and gauges, types related to date and
	time, and types for common string values (e.g., UUIDs, dotted-quad		time, and types for common string values (e.g., UUIDs, dotted-quad
	notation, and language tags).		notation, and language tags).

	* The "ietf-inet-types" module defines data types relevant for the		* The "ietf-inet-types" module defines data types relevant for the

	Internet protocol suite such as types related to IP address, types		Internet Protocol suite such as types related to IP address, types
	for domain name, host name, URI, and email, and types for values		for domain name, host name, URI, and email, and types for values
	in common protocol fields (e.g., port numbers).		in common protocol fields (e.g., port numbers).

	The initial version of these YANG modules was published as [RFC6021].		The initial version of these YANG modules was published as [RFC6021].
	The first revision of [RFC6021], published as [RFC6991], added		The first revision of [RFC6021], published as [RFC6991], added
	several type definitions to the YANG modules. This second revision		several type definitions to the YANG modules. This second revision
	adds further new type definitions and addresses Erratum IDs 4076		adds further new type definitions and addresses Erratum IDs 4076
	[Err4076] and 5105 [Err5105]. Furthermore, the yang-identifier		[Err4076] and 5105 [Err5105]. Furthermore, the yang-identifier
	definition has been aligned with YANG 1.1 [RFC7950], and some pattern		definition has been aligned with YANG 1.1 [RFC7950], and some pattern
	statements have been improved. For further details, see the revision		statements have been improved. For further details, see the revision

	skipping to change at line 120 ¶		skipping to change at line 120 ¶
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.

	2. Overview		2. Overview

	Tables 1 and 2 list the types defined in the YANG modules "ietf-yang-		Tables 1 and 2 list the types defined in the YANG modules "ietf-yang-
	types" and "ietf-inet-types". For each type, the name of the type,		types" and "ietf-inet-types". For each type, the name of the type,
	the base type it was derived from, and the RFC introducing the type		the base type it was derived from, and the RFC introducing the type
	is listed.		is listed.


	+=======================+===================+============+		+=======================+===================+===============+
	\| Type \| Base Type \| Introduced \|		\| Type \| Base Type \| Introduced in \|
	+=======================+===================+============+		+=======================+===================+===============+
	\| counter32 \| uint32 \| RFC 6021 \|		\| counter32 \| uint32 \| RFC 6021 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| zero-based-counter32 \| uint32 \| RFC 6021 \|		\| zero-based-counter32 \| uint32 \| RFC 6021 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| counter64 \| uint64 \| RFC 6021 \|		\| counter64 \| uint64 \| RFC 6021 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| zero-based-counter64 \| uint64 \| RFC 6021 \|		\| zero-based-counter64 \| uint64 \| RFC 6021 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| gauge32 \| uint32 \| RFC 6021 \|		\| gauge32 \| uint32 \| RFC 6021 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| gauge64 \| uint64 \| RFC 6021 \|		\| gauge64 \| uint64 \| RFC 6021 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| object-identifier \| string \| RFC 6021 \|		\| object-identifier \| string \| RFC 6021 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| object-identifier-128 \| object-identifier \| RFC 6021 \|		\| object-identifier-128 \| object-identifier \| RFC 6021 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| date-and-time \| string \| RFC 6021 \|		\| date-and-time \| string \| RFC 6021 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| date \| string \| RFC 9911 \|		\| date \| string \| RFC 9911 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| date-no-zone \| string \| RFC 9911 \|		\| date-no-zone \| string \| RFC 9911 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| time \| string \| RFC 9911 \|		\| time \| string \| RFC 9911 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| time-no-zone \| string \| RFC 9911 \|		\| time-no-zone \| string \| RFC 9911 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| hours32 \| int32 \| RFC 9911 \|		\| hours32 \| int32 \| RFC 9911 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| minutes32 \| int32 \| RFC 9911 \|		\| minutes32 \| int32 \| RFC 9911 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| seconds32 \| int32 \| RFC 9911 \|		\| seconds32 \| int32 \| RFC 9911 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| centiseconds32 \| int32 \| RFC 9911 \|		\| centiseconds32 \| int32 \| RFC 9911 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| milliseconds32 \| int32 \| RFC 9911 \|		\| milliseconds32 \| int32 \| RFC 9911 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| microseconds32 \| int32 \| RFC 9911 \|		\| microseconds32 \| int32 \| RFC 9911 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| microseconds64 \| int64 \| RFC 9911 \|		\| microseconds64 \| int64 \| RFC 9911 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| nanoseconds32 \| int32 \| RFC 9911 \|		\| nanoseconds32 \| int32 \| RFC 9911 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| nanoseconds64 \| int64 \| RFC 9911 \|		\| nanoseconds64 \| int64 \| RFC 9911 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| timeticks \| int32 \| RFC 6021 \|		\| timeticks \| int32 \| RFC 6021 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| timestamp \| timeticks \| RFC 6021 \|		\| timestamp \| timeticks \| RFC 6021 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| phys-address \| string \| RFC 6021 \|		\| phys-address \| string \| RFC 6021 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| mac-address \| string \| RFC 6021 \|		\| mac-address \| string \| RFC 6021 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| xpath1.0 \| string \| RFC 6021 \|		\| xpath1.0 \| string \| RFC 6021 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| hex-string \| string \| RFC 6991 \|		\| hex-string \| string \| RFC 6991 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| uuid \| string \| RFC 6991 \|		\| uuid \| string \| RFC 6991 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| dotted-quad \| string \| RFC 6991 \|		\| dotted-quad \| string \| RFC 6991 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| language-tag \| string \| RFC 9911 \|		\| language-tag \| string \| RFC 9911 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+
	\| yang-identifier \| string \| RFC 6991 \|		\| yang-identifier \| string \| RFC 6991 \|
	+-----------------------+-------------------+------------+		+-----------------------+-------------------+---------------+


	Table 1: Types Defined in the "ietf-yang-types" Module		Table 1: Types Defined in the "ietf-yang-types" Module


	+=============================+=================+============+		+=============================+=================+===============+
	\| Type \| Base Type \| Introduced \|		\| Type \| Base Type \| Introduced in \|
	+=============================+=================+============+		+=============================+=================+===============+
	\| ip-version \| enum \| RFC 6021 \|		\| ip-version \| enum \| RFC 6021 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| dscp \| uint8 \| RFC 6021 \|		\| dscp \| uint8 \| RFC 6021 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| ipv6-flow-label \| uint32 \| RFC 6021 \|		\| ipv6-flow-label \| uint32 \| RFC 6021 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| port-number \| uint16 \| RFC 6021 \|		\| port-number \| uint16 \| RFC 6021 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| protocol-number \| uint8 \| RFC 9911 \|		\| protocol-number \| uint8 \| RFC 9911 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| upper-layer-protocol-number \| protocol-number \| RFC 9911 \|		\| upper-layer-protocol-number \| protocol-number \| RFC 9911 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| as-number \| uint32 \| RFC 6021 \|		\| as-number \| uint32 \| RFC 6021 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| ip-address \| union \| RFC 6021 \|		\| ip-address \| union \| RFC 6021 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| ipv4-address \| string \| RFC 6021 \|		\| ipv4-address \| string \| RFC 6021 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| ipv6-address \| string \| RFC 6021 \|		\| ipv6-address \| string \| RFC 6021 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| ip-address-no-zone \| union \| RFC 6991 \|		\| ip-address-no-zone \| union \| RFC 6991 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| ipv4-address-no-zone \| ipv4-address \| RFC 6991 \|		\| ipv4-address-no-zone \| ipv4-address \| RFC 6991 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| ipv6-address-no-zone \| ipv6-address \| RFC 6991 \|		\| ipv6-address-no-zone \| ipv6-address \| RFC 6991 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| ip-address-link-local \| union \| RFC 9911 \|		\| ip-address-link-local \| union \| RFC 9911 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| ipv4-address-link-local \| ipv4-address \| RFC 9911 \|		\| ipv4-address-link-local \| ipv4-address \| RFC 9911 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| ipv6-address-link-local \| ipv6-address \| RFC 9911 \|		\| ipv6-address-link-local \| ipv6-address \| RFC 9911 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| ip-prefix \| union \| RFC 6021 \|		\| ip-prefix \| union \| RFC 6021 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| ipv4-prefix \| string \| RFC 6021 \|		\| ipv4-prefix \| string \| RFC 6021 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| ipv6-prefix \| string \| RFC 6021 \|		\| ipv6-prefix \| string \| RFC 6021 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| ip-address-and-prefix \| union \| RFC 9911 \|		\| ip-address-and-prefix \| union \| RFC 9911 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| ipv4-address-and-prefix \| string \| RFC 9911 \|		\| ipv4-address-and-prefix \| string \| RFC 9911 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| ipv6-address-and-prefix \| string \| RFC 9911 \|		\| ipv6-address-and-prefix \| string \| RFC 9911 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| domain-name \| string \| RFC 6021 \|		\| domain-name \| string \| RFC 6021 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| host-name \| domain-name \| RFC 9911 \|		\| host-name \| domain-name \| RFC 9911 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| host \| union \| RFC 6021 \|		\| host \| union \| RFC 6021 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| uri \| string \| RFC 6021 \|		\| uri \| string \| RFC 6021 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+
	\| email-address \| string \| RFC 9911 \|		\| email-address \| string \| RFC 9911 \|
	+-----------------------------+-----------------+------------+		+-----------------------------+-----------------+---------------+


	Table 2: Types Defined in the "ietf-inet-types" Module		Table 2: Types Defined in the "ietf-inet-types" Module

	Some types have an equivalent Structure of Management Information		Some types have an equivalent Structure of Management Information
	Version 2 (SMIv2) [RFC2578] [RFC2579] data type. A YANG data type is		Version 2 (SMIv2) [RFC2578] [RFC2579] data type. A YANG data type is
	equivalent to an SMIv2 data type if the data types have the same set		equivalent to an SMIv2 data type if the data types have the same set
	of values and the semantics of the values are equivalent.		of values and the semantics of the values are equivalent.

	Table 3 lists the types defined in the "ietf-yang-types" YANG module		Table 3 lists the types defined in the "ietf-yang-types" YANG module
	with their corresponding SMIv2 types, and Table 4 lists the types		with their corresponding SMIv2 types, and Table 4 lists the types
	defined in the "ietf-inet-types" module with their corresponding		defined in the "ietf-inet-types" module with their corresponding
	SMIv2 types.		SMIv2 types.

	skipping to change at line 313 ¶		skipping to change at line 313 ¶
	+-----------------+-----------------------------------------------+		+-----------------+-----------------------------------------------+
	\| as-number \| InetAutonomousSystemNumber (INET-ADDRESS-MIB) \|		\| as-number \| InetAutonomousSystemNumber (INET-ADDRESS-MIB) \|
	+-----------------+-----------------------------------------------+		+-----------------+-----------------------------------------------+
	\| uri \| Uri (URI-TC-MIB) \|		\| uri \| Uri (URI-TC-MIB) \|
	+-----------------+-----------------------------------------------+		+-----------------+-----------------------------------------------+

	Table 4: Equivalent SMIv2 Types for the "ietf-inet-types" Module		Table 4: Equivalent SMIv2 Types for the "ietf-inet-types" Module

	3. Core YANG Types		3. Core YANG Types


	The "ietf-yang-types" YANG module references [IEEE-802-2001],		The "ietf-yang-types" YANG module references [IEEE-802-2024],
	[ISO-9834-1], [RFC2578], [RFC2579], [RFC2856], [RFC3339], [RFC4122],		[ISO-8601], [ISO-9834-1], [RFC2578], [RFC2579], [RFC2856], [RFC3339],
	[RFC4502], [RFC5131], [RFC5646], [RFC7950], [RFC8294], [RFC9557],		[RFC4502], [RFC5131], [RFC5646], [RFC7950], [RFC9557], [RFC9562],
	[XPATH], and [XSD-TYPES].		[XPATH], and [XSD-TYPES].

	<CODE BEGINS> file "ietf-yang-types@2025-12-01.yang"		<CODE BEGINS> file "ietf-yang-types@2025-12-01.yang"
	module ietf-yang-types {		module ietf-yang-types {
	namespace "urn:ietf:params:xml:ns:yang:ietf-yang-types";		namespace "urn:ietf:params:xml:ns:yang:ietf-yang-types";
	prefix yang;		prefix yang;

	organization		organization
	"IETF Network Modeling (NETMOD) Working Group";		"IETF Network Modeling (NETMOD) Working Group";
	contact		contact
	"WG Web: <https://datatracker.ietf.org/wg/netmod/>		"WG Web: <https://datatracker.ietf.org/wg/netmod/>
	WG List: <mailto:netmod@ietf.org>		WG List: <mailto:netmod@ietf.org>


	Editor: Juergen Schoenwaelder		Editor: Jürgen Schönwälder
	<mailto:jschoenwaelder@constructor.university>";		<mailto:jschoenwaelder@constructor.university>";
	description		description
	"This module contains a collection of generally useful derived		"This module contains a collection of generally useful derived
	YANG data types.		YANG data types.

	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
	NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',		NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
	'MAY', and 'OPTIONAL' in this document are to be interpreted as		'MAY', and 'OPTIONAL' in this document are to be interpreted as
	described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,		described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
	they appear in all capitals, as shown here.		they appear in all capitals, as shown here.

	skipping to change at line 411 ¶		skipping to change at line 411 ¶
	"The counter32 type represents a non-negative integer		"The counter32 type represents a non-negative integer
	that monotonically increases until it reaches a		that monotonically increases until it reaches a
	maximum value of 2^32-1 (4294967295 decimal), when it		maximum value of 2^32-1 (4294967295 decimal), when it
	wraps around and starts increasing again from zero.		wraps around and starts increasing again from zero.

	Counters have no defined 'initial' value, and thus, a		Counters have no defined 'initial' value, and thus, a
	single value of a counter has (in general) no information		single value of a counter has (in general) no information
	content. Discontinuities in the monotonically increasing		content. Discontinuities in the monotonically increasing
	value normally occur at re-initialization of the		value normally occur at re-initialization of the
	management system and at other times as specified in the		management system and at other times as specified in the

	description of a schema node using this type. If such		description of a schema node using this type. If
	other times can occur, for example, the instantiation of		discontinuities occur at times other than re-initialization
	a schema node of type counter32 at times other than		(for example, at the instantiation of a schema node of type
	re-initialization, then a corresponding schema node		counter32), then a corresponding schema node should be
	should be defined, with an appropriate type, to indicate		defined, with an appropriate type, to indicate the last
	the last discontinuity.		discontinuity.

	The counter32 type should not be used for configuration		The counter32 type should not be used for configuration
	schema nodes. A default statement SHOULD NOT be used in		schema nodes. A default statement SHOULD NOT be used in
	combination with the type counter32.		combination with the type counter32.

	In the value set and its semantics, this type is equivalent		In the value set and its semantics, this type is equivalent
	to the Counter32 type of the SMIv2.";		to the Counter32 type of the SMIv2.";
	reference		reference
	"RFC 2578: Structure of Management Information Version 2		"RFC 2578: Structure of Management Information Version 2
	(SMIv2)";		(SMIv2)";

	skipping to change at line 468 ¶		skipping to change at line 468 ¶
	"The counter64 type represents a non-negative integer		"The counter64 type represents a non-negative integer
	that monotonically increases until it reaches a		that monotonically increases until it reaches a
	maximum value of 2^64-1 (18446744073709551615 decimal),		maximum value of 2^64-1 (18446744073709551615 decimal),
	when it wraps around and starts increasing again from zero.		when it wraps around and starts increasing again from zero.

	Counters have no defined 'initial' value, and thus, a		Counters have no defined 'initial' value, and thus, a
	single value of a counter has (in general) no information		single value of a counter has (in general) no information
	content. Discontinuities in the monotonically increasing		content. Discontinuities in the monotonically increasing
	value normally occur at re-initialization of the		value normally occur at re-initialization of the
	management system and at other times as specified in the		management system and at other times as specified in the

	description of a schema node using this type. If such		description of a schema node using this type. If
	other times can occur, for example, the instantiation of		discontinuities occur at times other than re-initialization
	a schema node of type counter64 at times other than		(for example, at the instantiation of a schema node of type
	re-initialization, then a corresponding schema node		counter64), then a corresponding schema node should be
	should be defined, with an appropriate type, to indicate		defined, with an appropriate type, to indicate the last
	the last discontinuity.		discontinuity.

	The counter64 type should not be used for configuration		The counter64 type should not be used for configuration
	schema nodes. A default statement SHOULD NOT be used in		schema nodes. A default statement SHOULD NOT be used in
	combination with the type counter64.		combination with the type counter64.

	In the value set and its semantics, this type is equivalent		In the value set and its semantics, this type is equivalent
	to the Counter64 type of the SMIv2.";		to the Counter64 type of the SMIv2.";
	reference		reference
	"RFC 2578: Structure of Management Information Version 2		"RFC 2578: Structure of Management Information Version 2
	(SMIv2)";		(SMIv2)";

	skipping to change at line 525 ¶		skipping to change at line 525 ¶
	description		description
	"The gauge32 type represents a non-negative integer, which		"The gauge32 type represents a non-negative integer, which
	may increase or decrease, but shall never exceed a maximum		may increase or decrease, but shall never exceed a maximum
	value, nor fall below a minimum value. The maximum value		value, nor fall below a minimum value. The maximum value
	cannot be greater than 2^32-1 (4294967295 decimal), and		cannot be greater than 2^32-1 (4294967295 decimal), and
	the minimum value cannot be smaller than 0. The value of		the minimum value cannot be smaller than 0. The value of
	a gauge32 has its maximum value whenever the information		a gauge32 has its maximum value whenever the information
	being modeled is greater than or equal to its maximum		being modeled is greater than or equal to its maximum
	value, and has its minimum value whenever the information		value, and has its minimum value whenever the information
	being modeled is smaller than or equal to its minimum value.		being modeled is smaller than or equal to its minimum value.

	If the information being modeled subsequently decreases		If the information being modeled subsequently decreases below
	below (increases above) the maximum (minimum) value, the		the maximum value, the gauge32 also decreases; likewise, if
	gauge32 also decreases (increases).		the information increases above the minimum value, the
			gauge32 also increases.

	In the value set and its semantics, this type is equivalent		In the value set and its semantics, this type is equivalent
	to the Gauge32 type of the SMIv2.";		to the Gauge32 type of the SMIv2.";
	reference		reference
	"RFC 2578: Structure of Management Information Version 2		"RFC 2578: Structure of Management Information Version 2
	(SMIv2)";		(SMIv2)";
	}		}

	typedef gauge64 {		typedef gauge64 {
	type uint64;		type uint64;

	skipping to change at line 596 ¶		skipping to change at line 597 ¶
	module designers should realize that there may be		module designers should realize that there may be
	implementations that stick with the SMIv2 limit of 128		implementations that stick with the SMIv2 limit of 128
	sub-identifiers.		sub-identifiers.

	This type is a superset of the SMIv2 OBJECT IDENTIFIER type		This type is a superset of the SMIv2 OBJECT IDENTIFIER type
	since it is not restricted to 128 sub-identifiers. Hence,		since it is not restricted to 128 sub-identifiers. Hence,
	this type SHOULD NOT be used to represent the SMIv2 OBJECT		this type SHOULD NOT be used to represent the SMIv2 OBJECT
	IDENTIFIER type; the object-identifier-128 type SHOULD be		IDENTIFIER type; the object-identifier-128 type SHOULD be
	used instead.";		used instead.";
	reference		reference

	"ISO 9834-1: Information technology -- Open Systems		"ISO 9834-1: Information technology -- Procedures for the
	Interconnection -- Procedures for the operation of OSI		operation of object identifier registration authorities -
	Registration Authorities: General procedures and top		Part 1: General procedures and top arcs of the international
	arcs of the International Object Identifier tree";		object identifier tree";
	}		}

	typedef object-identifier-128 {		typedef object-identifier-128 {
	type object-identifier {		type object-identifier {
	pattern '[0-9](\.[0-9]){1,127}';		pattern '[0-9](\.[0-9]){1,127}';
	}		}
	description		description
	"This type represents object-identifiers restricted to 128		"This type represents object-identifiers restricted to 128
	sub-identifiers.		sub-identifiers.


	skipping to change at line 623 ¶		skipping to change at line 624 ¶
	"RFC 2578: Structure of Management Information Version 2		"RFC 2578: Structure of Management Information Version 2
	(SMIv2)";		(SMIv2)";
	}		}

	/* collection of types related to date and time */		/* collection of types related to date and time */

	typedef date-and-time {		typedef date-and-time {
	type string {		type string {
	pattern		pattern
	'[0-9]{4}-(1[0-2]\|0[1-9])-(0[1-9]\|[1-2][0-9]\|3[0-1])'		'[0-9]{4}-(1[0-2]\|0[1-9])-(0[1-9]\|[1-2][0-9]\|3[0-1])'

	+ 'T(0[0-9]\|1[0-9]\|2[0-3]):[0-5][0-9]:([0-5][0-9]\|60)(\.[0-9]+)?'		+ 'T(0[0-9]\|1[0-9]\|2[0-3]):[0-5][0-9]:([0-5][0-9]\|60)'
			+ '(\.[0-9]+)?'
	+ '(Z\|[\+\-]((1[0-3]\|0[0-9]):([0-5][0-9])\|14:00))?';		+ '(Z\|[\+\-]((1[0-3]\|0[0-9]):([0-5][0-9])\|14:00))?';
	}		}
	description		description
	"The date-and-time type is a profile of the ISO 8601		"The date-and-time type is a profile of the ISO 8601
	standard for representation of dates and times using the		standard for representation of dates and times using the
	Gregorian calendar. The profile is defined by the		Gregorian calendar. The profile is defined by the
	date-time production in Section 5.6 of RFC 3339 and the		date-time production in Section 5.6 of RFC 3339 and the
	update defined in Section 2 of RFC 9557. The value of		update defined in Section 2 of RFC 9557. The value of
	60 for seconds is allowed only in the case of leap seconds.		60 for seconds is allowed only in the case of leap seconds.

	The date-and-time type is compatible with the dateTime XML		The date-and-time type is compatible with the dateTime XML
	schema dateTime type with the following notable exceptions:		schema dateTime type with the following notable exceptions:

	(a) The date-and-time type does not allow negative years.		(a) The date-and-time type does not allow negative years.

	(b) The time-offset Z indicates that the date-and-time		(b) The time-offset Z indicates that the date-and-time
	value is reported in UTC and that the local time zone		value is reported in UTC and that the local time zone
	reference point is unknown. The time-offset +00:00		reference point is unknown. The time-offset +00:00
	indicates that the date-and-time value is reported in		indicates that the date-and-time value is reported in

	UTC and that the local time reference point is UTC		UTC and that the local time zone reference point is UTC
	(see Section 2 of RFC 9557).		(see Section 2 of RFC 9557).

	This type is not equivalent to the DateAndTime textual		This type is not equivalent to the DateAndTime textual
	convention of the SMIv2 since RFC 3339 uses a different		convention of the SMIv2 since RFC 3339 uses a different
	separator between full-date and full-time and provides		separator between full-date and full-time and provides
	higher resolution of time-secfrac.		higher resolution of time-secfrac.

	The canonical format for date-and-time values with a known		The canonical format for date-and-time values with a known
	time zone uses a numeric time zone offset that is calculated		time zone uses a numeric time zone offset that is calculated
	using the device's configured known offset to UTC time. A		using the device's configured known offset to UTC time. A
	change of the device's offset to UTC time will cause		change of the device's offset to UTC time will cause
	date-and-time values to change accordingly. Such changes		date-and-time values to change accordingly. Such changes

	might happen periodically in case a server follows		might happen periodically if a server automatically follows
	automatically daylight saving time (DST) time zone offset		daylight saving time (DST) time zone offset changes. The
	changes. The canonical format for date-and-time values		canonical format for date-and-time values reported in UTC
	reported in UTC with an unknown local time zone offset SHOULD		with an unknown local time zone offset SHOULD use the
	use the time-offset Z and MAY use -00:00 for backwards		time-offset Z and MAY use -00:00 for backwards
	compatibility.";		compatibility.";
	reference		reference

	"RFC 3339: Date and Time on the Internet: Timestamps		"ISO 8601: Data elements and interchange formats -- Information
			interchange -- Representation of dates and times
			RFC 3339: Date and Time on the Internet: Timestamps
	RFC 9557: Date and Time on the Internet: Timestamps		RFC 9557: Date and Time on the Internet: Timestamps
	with Additional Information		with Additional Information
	RFC 2579: Textual Conventions for SMIv2		RFC 2579: Textual Conventions for SMIv2
	XSD-TYPES: XML Schema Definition Language (XSD) 1.1		XSD-TYPES: XML Schema Definition Language (XSD) 1.1
	Part 2: Datatypes";		Part 2: Datatypes";
	}		}

	typedef date {		typedef date {
	type string {		type string {
	pattern '[0-9]{4}-(1[0-2]\|0[1-9])-(0[1-9]\|[1-2][0-9]\|3[0-1])'		pattern '[0-9]{4}-(1[0-2]\|0[1-9])-(0[1-9]\|[1-2][0-9]\|3[0-1])'

	skipping to change at line 690 ¶		skipping to change at line 694 ¶

	The date type is compatible with the XML schema date		The date type is compatible with the XML schema date
	type with the following notable exceptions:		type with the following notable exceptions:

	(a) The date type does not allow negative years.		(a) The date type does not allow negative years.

	(b) The time-offset Z indicates that the date value is		(b) The time-offset Z indicates that the date value is
	reported in UTC and that the local time zone reference		reported in UTC and that the local time zone reference
	point is unknown. The time-offset +00:00 indicates that		point is unknown. The time-offset +00:00 indicates that
	the date value is reported in UTC and that the local		the date value is reported in UTC and that the local

	time reference point is UTC (see Section 2 of RFC 9557).		time zone reference point is UTC (see Section 2 of
			RFC 9557).

	The canonical format for date values with a known time		The canonical format for date values with a known time
	zone uses a numeric time zone offset that is calculated using		zone uses a numeric time zone offset that is calculated using
	the device's configured known offset to UTC time. A change of		the device's configured known offset to UTC time. A change of
	the device's offset to UTC time will cause date values		the device's offset to UTC time will cause date values
	to change accordingly. Such changes might happen periodically		to change accordingly. Such changes might happen periodically

	in case a server follows automatically daylight saving time		if a server automatically follows daylight saving time
	(DST) time zone offset changes. The canonical format for		(DST) time zone offset changes. The canonical format for
	date values reported in UTC with an unknown local time zone		date values reported in UTC with an unknown local time zone
	offset uses the time-offset Z.";		offset uses the time-offset Z.";
	reference		reference
	"RFC 3339: Date and Time on the Internet: Timestamps		"RFC 3339: Date and Time on the Internet: Timestamps
	RFC 9557: Date and Time on the Internet: Timestamps		RFC 9557: Date and Time on the Internet: Timestamps
	with Additional Information		with Additional Information
	XSD-TYPES: XML Schema Definition Language (XSD) 1.1		XSD-TYPES: XML Schema Definition Language (XSD) 1.1
	Part 2: Datatypes";		Part 2: Datatypes";
	}		}

	skipping to change at line 721 ¶		skipping to change at line 726 ¶
	pattern '[0-9]{4}-(1[0-2]\|0[1-9])-(0[1-9]\|[1-2][0-9]\|3[0-1])';		pattern '[0-9]{4}-(1[0-2]\|0[1-9])-(0[1-9]\|[1-2][0-9]\|3[0-1])';
	}		}
	description		description
	"The date-no-zone type represents a date without the optional		"The date-no-zone type represents a date without the optional
	time zone offset information.";		time zone offset information.";
	}		}

	typedef time {		typedef time {
	type string {		type string {
	pattern		pattern

	'(0[0-9]\|1[0-9]\|2[0-3]):[0-5][0-9]:([0-5][0-9]\|60)(\.[0-9]+)?'		'(0[0-9]\|1[0-9]\|2[0-3]):[0-5][0-9]:([0-5][0-9]\|60)'
			+ '(\.[0-9]+)?'
	+ '(Z\|[\+\-]((1[0-3]\|0[0-9]):([0-5][0-9])\|14:00))?';		+ '(Z\|[\+\-]((1[0-3]\|0[0-9]):([0-5][0-9])\|14:00))?';
	}		}
	description		description
	"The time type represents an instance of time of zero duration		"The time type represents an instance of time of zero duration
	that recurs every day. It includes an optional time zone		that recurs every day. It includes an optional time zone
	offset. The value of 60 for seconds is allowed only in the		offset. The value of 60 for seconds is allowed only in the
	case of leap seconds.		case of leap seconds.

	The time type is compatible with the XML schema time		The time type is compatible with the XML schema time
	type with the following notable exception:		type with the following notable exception:

	(a) The time-offset Z indicates that the time value is		(a) The time-offset Z indicates that the time value is
	reported in UTC and that the local time zone reference		reported in UTC and that the local time zone reference
	point is unknown. The time-offset +00:00 indicates that		point is unknown. The time-offset +00:00 indicates that
	the time value is reported in UTC and that the local		the time value is reported in UTC and that the local

	time reference point is UTC (see Section 2 of RFC 9557).		time zone reference point is UTC (see Section 2 of
			RFC 9557).

	The canonical format for time values with a known time		The canonical format for time values with a known time
	zone uses a numeric time zone offset that is calculated using		zone uses a numeric time zone offset that is calculated using
	the device's configured known offset to UTC time. A change of		the device's configured known offset to UTC time. A change of
	the device's offset to UTC time will cause time values		the device's offset to UTC time will cause time values
	to change accordingly. Such changes might happen periodically		to change accordingly. Such changes might happen periodically

	in case a server follows automatically daylight saving time		if a server automatically follows daylight saving time
	(DST) time zone offset changes. The canonical format for		(DST) time zone offset changes. The canonical format for
	time values reported in UTC with an unknown local time zone		time values reported in UTC with an unknown local time zone
	offset uses the time-offset Z.";		offset uses the time-offset Z.";
	reference		reference
	"RFC 3339: Date and Time on the Internet: Timestamps		"RFC 3339: Date and Time on the Internet: Timestamps
	RFC 9557: Date and Time on the Internet: Timestamps		RFC 9557: Date and Time on the Internet: Timestamps
	with Additional Information		with Additional Information
	XSD-TYPES: XML Schema Definition Language (XSD) 1.1		XSD-TYPES: XML Schema Definition Language (XSD) 1.1
	Part 2: Datatypes";		Part 2: Datatypes";
	}		}

	typedef time-no-zone {		typedef time-no-zone {
	type time {		type time {
	pattern		pattern

	'(0[0-9]\|1[0-9]\|2[0-3]):[0-5][0-9]:([0-5][0-9]\|60)(\.[0-9]+)?';		'(0[0-9]\|1[0-9]\|2[0-3]):[0-5][0-9]:([0-5][0-9]\|60)'
			+ '(\.[0-9]+)?';
	}		}
	description		description
	"The time-no-zone type represents a time without the optional		"The time-no-zone type represents a time without the optional
	time zone offset information.";		time zone offset information.";
	}		}

	typedef hours32 {		typedef hours32 {
	type int32;		type int32;
	units "hours";		units "hours";
	description		description

	skipping to change at line 1003 ¶		skipping to change at line 1011 ¶
	lowercase characters.";		lowercase characters.";
	}		}

	typedef uuid {		typedef uuid {
	type string {		type string {
	pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-'		pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-'
	+ '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}';		+ '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}';
	}		}
	description		description
	"A Universally Unique IDentifier in the string representation		"A Universally Unique IDentifier in the string representation

	defined in RFC 4122. The canonical representation uses		defined in RFC 9562. The canonical representation uses
	lowercase characters.		lowercase characters.

	The following is an example of a UUID in string		The following is an example of a UUID in string
	representation:		representation:
	f81d4fae-7dec-11d0-a765-00a0c91e6bf6.		f81d4fae-7dec-11d0-a765-00a0c91e6bf6.
	";		";
	reference		reference

	"RFC 4122: A Universally Unique IDentifier (UUID) URN		"RFC 9562: Universally Unique IDentifiers (UUIDs)";
	Namespace";
	}		}

	typedef dotted-quad {		typedef dotted-quad {
	type string {		type string {
	pattern		pattern
	'(([0-9]\|[1-9][0-9]\|1[0-9][0-9]\|2[0-4][0-9]\|25[0-5])\.){3}'		'(([0-9]\|[1-9][0-9]\|1[0-9][0-9]\|2[0-4][0-9]\|25[0-5])\.){3}'
	+ '([0-9]\|[1-9][0-9]\|1[0-9][0-9]\|2[0-4][0-9]\|25[0-5])';		+ '([0-9]\|[1-9][0-9]\|1[0-9][0-9]\|2[0-4][0-9]\|25[0-5])';
	}		}
	description		description
	"An unsigned 32-bit number expressed in the dotted-quad		"An unsigned 32-bit number expressed in the dotted-quad

	skipping to change at line 1063 ¶		skipping to change at line 1070 ¶
	pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';		pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
	}		}
	description		description
	"A YANG identifier string as defined by the 'identifier'		"A YANG identifier string as defined by the 'identifier'
	rule in Section 14 of RFC 7950. An identifier must		rule in Section 14 of RFC 7950. An identifier must
	start with an alphabetic character or an underscore		start with an alphabetic character or an underscore
	followed by an arbitrary sequence of alphabetic or		followed by an arbitrary sequence of alphabetic or
	numeric characters, underscores, hyphens, or dots.		numeric characters, underscores, hyphens, or dots.

	This definition conforms to YANG 1.1 defined in RFC		This definition conforms to YANG 1.1 defined in RFC

	7950. An earlier version of this definition excluded		7950. In RFC 6991, this definition excluded
	all identifiers starting with any possible combination		all identifiers starting with any possible combination
	of the lowercase or uppercase character sequence 'xml',		of the lowercase or uppercase character sequence 'xml',
	as required by YANG 1 defined in RFC 6020. If this type		as required by YANG 1 defined in RFC 6020. If this type
	is used in a YANG 1 context, then this restriction still		is used in a YANG 1 context, then this restriction still
	applies.";		applies.";
	reference		reference
	"RFC 7950: The YANG 1.1 Data Modeling Language		"RFC 7950: The YANG 1.1 Data Modeling Language
	RFC 6020: YANG - A Data Modeling Language for the		RFC 6020: YANG - A Data Modeling Language for the
	Network Configuration Protocol (NETCONF)";		Network Configuration Protocol (NETCONF)";
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>

	4. Internet Protocol Suite Types		4. Internet Protocol Suite Types

	The "ietf-inet-types" YANG module references [RFC0768], [RFC0791],		The "ietf-inet-types" YANG module references [RFC0768], [RFC0791],
	[RFC0952], [RFC1034], [RFC1123], [RFC1930], [RFC2317], [RFC2474],		[RFC0952], [RFC1034], [RFC1123], [RFC1930], [RFC2317], [RFC2474],
	[RFC2780], [RFC2782], [RFC3289], [RFC3305], [RFC3595], [RFC3927],		[RFC2780], [RFC2782], [RFC3289], [RFC3305], [RFC3595], [RFC3927],
	[RFC3986], [RFC4001], [RFC4007], [RFC4271], [RFC4291], [RFC4340],		[RFC3986], [RFC4001], [RFC4007], [RFC4271], [RFC4291], [RFC4340],

	[RFC4592], [RFC5017], [RFC5322], [RFC5890], [RFC5952], [RFC6793],		[RFC4592], [RFC5017], [RFC5322], [RFC5890], [RFC5952], [RFC6532],
	[RFC8200], [RFC9260], [RFC9293], and [RFC9499].		[RFC6793], [RFC8200], [RFC9260], [RFC9293], and [RFC9499].

	<CODE BEGINS> file "ietf-inet-types@2025-12-01.yang"		<CODE BEGINS> file "ietf-inet-types@2025-12-01.yang"
	module ietf-inet-types {		module ietf-inet-types {
	namespace "urn:ietf:params:xml:ns:yang:ietf-inet-types";		namespace "urn:ietf:params:xml:ns:yang:ietf-inet-types";
	prefix inet;		prefix inet;

	organization		organization
	"IETF Network Modeling (NETMOD) Working Group";		"IETF Network Modeling (NETMOD) Working Group";
	contact		contact
	"WG Web: <https://datatracker.ietf.org/wg/netmod/>		"WG Web: <https://datatracker.ietf.org/wg/netmod/>
	WG List: <mailto:netmod@ietf.org>		WG List: <mailto:netmod@ietf.org>


	Editor: Juergen Schoenwaelder		Editor: Jürgen Schönwälder
	<mailto:jschoenwaelder@constructor.university>";		<mailto:jschoenwaelder@constructor.university>";
	description		description
	"This module contains a collection of generally useful derived		"This module contains a collection of generally useful derived
	YANG data types for Internet addresses and related things.		YANG data types for Internet addresses and related things.

	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
	NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',		NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
	'MAY', and 'OPTIONAL' in this document are to be interpreted as		'MAY', and 'OPTIONAL' in this document are to be interpreted as
	described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,		described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
	they appear in all capitals, as shown here.		they appear in all capitals, as shown here.

	skipping to change at line 1165 ¶		skipping to change at line 1172 ¶
	}		}

	/* collection of types related to protocol fields */		/* collection of types related to protocol fields */

	typedef ip-version {		typedef ip-version {
	type enumeration {		type enumeration {
	enum unknown {		enum unknown {
	value 0;		value 0;
	description		description
	"An unknown or unspecified version of the Internet		"An unknown or unspecified version of the Internet

	protocol.";		Protocol.";
	}		}
	enum ipv4 {		enum ipv4 {
	value 1;		value 1;
	description		description
	"The IPv4 protocol as defined in RFC 791.";		"The IPv4 protocol as defined in RFC 791.";
	}		}
	enum ipv6 {		enum ipv6 {
	value 2;		value 2;
	description		description
	"The IPv6 protocol as defined in RFC 8200.";		"The IPv6 protocol as defined in RFC 8200.";
	}		}
	}		}
	description		description

	"This value represents the version of the IP protocol.		"This value represents the version of the Internet Protocol.

	In the value set and its semantics, this type is equivalent		In the value set and its semantics, this type is equivalent
	to the InetVersion textual convention of the SMIv2.";		to the InetVersion textual convention of the SMIv2.";
	reference		reference
	"RFC 791: Internet Protocol		"RFC 791: Internet Protocol
	RFC 8200: Internet Protocol, Version 6 (IPv6) Specification		RFC 8200: Internet Protocol, Version 6 (IPv6) Specification
	RFC 4001: Textual Conventions for Internet Network Addresses";		RFC 4001: Textual Conventions for Internet Network Addresses";
	}		}

	typedef dscp {		typedef dscp {

	skipping to change at line 1254 ¶		skipping to change at line 1261 ¶
	RFC 9293: Transmission Control Protocol (TCP)		RFC 9293: Transmission Control Protocol (TCP)
	RFC 9260: Stream Control Transmission Protocol		RFC 9260: Stream Control Transmission Protocol
	RFC 4340: Datagram Congestion Control Protocol (DCCP)		RFC 4340: Datagram Congestion Control Protocol (DCCP)
	RFC 4001: Textual Conventions for Internet Network Addresses";		RFC 4001: Textual Conventions for Internet Network Addresses";
	}		}

	typedef protocol-number {		typedef protocol-number {
	type uint8;		type uint8;
	description		description
	"The protocol-number type represents an 8-bit Internet		"The protocol-number type represents an 8-bit Internet

	protocol number, carried in the 'protocol' field of the		Protocol number, carried in the 'protocol' field of the
	IPv4 header or in the 'next header' field of the IPv6		IPv4 header or in the 'next header' field of the IPv6
	header.		header.

	Protocol numbers are assigned by IANA. The current list of		Protocol numbers are assigned by IANA. The current list of
	all assignments is available from <https://www.iana.org/>.";		all assignments is available from <https://www.iana.org/>.";
	reference		reference
	"RFC 791: Internet Protocol		"RFC 791: Internet Protocol
	RFC 8200: Internet Protocol, Version 6 (IPv6) Specification";		RFC 8200: Internet Protocol, Version 6 (IPv6) Specification";
	}		}


	skipping to change at line 1289 ¶		skipping to change at line 1296 ¶

	typedef as-number {		typedef as-number {
	type uint32;		type uint32;
	description		description
	"The as-number type represents autonomous system numbers		"The as-number type represents autonomous system numbers
	that identify an Autonomous System (AS). An AS is a set		that identify an Autonomous System (AS). An AS is a set
	of routers under a single technical administration, using		of routers under a single technical administration, using
	an interior gateway protocol and common metrics to route		an interior gateway protocol and common metrics to route
	packets within the AS, and using an exterior gateway		packets within the AS, and using an exterior gateway
	protocol to route packets to other ASes. IANA maintains		protocol to route packets to other ASes. IANA maintains

	the AS number space and has delegated large parts to the		the autonomous system number space and has delegated large
	regional registries.		parts to the regional registries.

	Autonomous system numbers were originally limited to 16		Autonomous system numbers were originally limited to 16
	bits. BGP extensions have enlarged the autonomous system		bits. BGP extensions have enlarged the autonomous system
	number space to 32 bits. This type therefore uses an uint32		number space to 32 bits. This type therefore uses an uint32
	base type without a range restriction in order to support		base type without a range restriction in order to support
	a larger autonomous system number space.		a larger autonomous system number space.

	In the value set and its semantics, this type is equivalent		In the value set and its semantics, this type is equivalent
	to the InetAutonomousSystemNumber textual convention of		to the InetAutonomousSystemNumber textual convention of
	the SMIv2.";		the SMIv2.";

	skipping to change at line 1603 ¶		skipping to change at line 1610 ¶
	reference		reference
	"RFC 5952: A Recommendation for IPv6 Address Text		"RFC 5952: A Recommendation for IPv6 Address Text
	Representation";		Representation";
	}		}

	/* collection of domain name and URI types */		/* collection of domain name and URI types */

	typedef domain-name {		typedef domain-name {
	type string {		type string {
	length "1..253";		length "1..253";

	pattern '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*'		pattern
	+ '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'		'((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*'
	+ '\|\.';		+ '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'
			+ '\|\.';
	}		}
	description		description
	"The domain-name type represents a DNS domain name. The		"The domain-name type represents a DNS domain name. The
	name SHOULD be fully qualified whenever possible. This		name SHOULD be fully qualified whenever possible. This
	type does not support wildcards (see RFC 4592) or		type does not support wildcards (see RFC 4592) or
	classless in-addr.arpa delegations (see RFC 2317).		classless in-addr.arpa delegations (see RFC 2317).

	Internet domain names are only loosely specified. Section		Internet domain names are only loosely specified. Section
	3.5 of RFC 1034 recommends a syntax (modified in Section		3.5 of RFC 1034 recommends a syntax (modified in Section
	2.1 of RFC 1123). The pattern above is intended to allow		2.1 of RFC 1123). The pattern above is intended to allow
	for current practice in domain name use and some possible		for current practice in domain name use and some possible
	future expansion. Note that Internet host names have a		future expansion. Note that Internet host names have a
	stricter syntax (described in RFC 952) than the DNS		stricter syntax (described in RFC 952) than the DNS
	recommendations in RFCs 1034 and 1123. Schema nodes		recommendations in RFCs 1034 and 1123. Schema nodes
	representing host names should use the host-name type		representing host names should use the host-name type
	instead of the domain-type.		instead of the domain-type.

	The encoding of DNS names in the DNS protocol is limited		The encoding of DNS names in the DNS protocol is limited
	to 255 characters. Since the encoding consists of labels		to 255 characters. Since the encoding consists of labels

	prefixed by a length bytes and there is a trailing NULL		prefixed by a length byte and there is a trailing NUL
	byte, only 253 characters can appear in the textual dotted		byte, only 253 characters can appear in the textual dotted
	notation.		notation.

	The description clause of schema nodes using the domain-name		The description clause of schema nodes using the domain-name
	type MUST describe when and how these names are resolved to		type MUST describe when and how these names are resolved to
	IP addresses. Note that the resolution of a domain-name value		IP addresses. Note that the resolution of a domain-name value
	may require to query multiple DNS records (e.g., A for IPv4		may require to query multiple DNS records (e.g., A for IPv4
	and AAAA for IPv6). The order of the resolution process and		and AAAA for IPv6). The order of the resolution process and
	which DNS record takes precedence can either be defined		which DNS record takes precedence can either be defined
	explicitly or depend on the configuration of the		explicitly or depend on the configuration of the
	resolver.		resolver.


	Domain-name values use the US-ASCII encoding. Their canonical		Domain-name values use the ASCII encoding. Their canonical
	format uses lowercase US-ASCII characters. Internationalized		format uses lowercase ASCII characters. Internationalized
	domain names MUST be A-labels as per RFC 5890.";		domain names MUST be A-labels as per RFC 5890.";
	reference		reference
	"RFC 952: DoD Internet Host Table Specification		"RFC 952: DoD Internet Host Table Specification
	RFC 1034: Domain Names - Concepts and Facilities		RFC 1034: Domain Names - Concepts and Facilities
	RFC 1123: Requirements for Internet Hosts -- Application		RFC 1123: Requirements for Internet Hosts -- Application
	and Support		and Support
	RFC 2317: Classless IN-ADDR.ARPA delegation		RFC 2317: Classless IN-ADDR.ARPA delegation
	RFC 2782: A DNS RR for specifying the location of services		RFC 2782: A DNS RR for specifying the location of services
	(DNS SRV)		(DNS SRV)
	RFC 4592: The Role of Wildcards in the Domain Name System		RFC 4592: The Role of Wildcards in the Domain Name System

	skipping to change at line 1661 ¶		skipping to change at line 1669 ¶
	(IDNA): Definitions and Document Framework		(IDNA): Definitions and Document Framework
	RFC 9499: DNS Terminology";		RFC 9499: DNS Terminology";
	}		}

	typedef host-name {		typedef host-name {
	type domain-name {		type domain-name {
	length "2..max";		length "2..max";
	pattern '[a-zA-Z0-9\-\.]+';		pattern '[a-zA-Z0-9\-\.]+';
	}		}
	description		description

	"The host-name type represents (fully qualified) host names.		"The host-name type represents fully qualified host names.
	Host names must be at least two characters long (see RFC 952),		Host names must be at least two characters long (see RFC 952),
	and they are restricted to labels consisting of letters,		and they are restricted to labels consisting of letters,
	digits, and hyphens separated by dots (see RFCs 1123 and		digits, and hyphens separated by dots (see RFCs 1123 and
	952).";		952).";
	reference		reference
	"RFC 952: DoD Internet Host Table Specification		"RFC 952: DoD Internet Host Table Specification
	RFC 1123: Requirements for Internet Hosts -- Application		RFC 1123: Requirements for Internet Hosts -- Application
	and Support";		and Support";
	}		}

	typedef host {		typedef host {
	type union {		type union {
	type ip-address;		type ip-address;
	type host-name;		type host-name;
	}		}
	description		description

	"The host type represents either an IP address or a (fully		"The host type represents either an IP address or a fully
	qualified) host name.";		qualified host name.";
	}		}

	typedef uri {		typedef uri {
	type string {		type string {
	pattern '[a-z][a-z0-9+.-]:.';		pattern '[a-z][a-z0-9+.-]:.';
	}		}
	description		description
	"The uri type represents a Uniform Resource Identifier		"The uri type represents a Uniform Resource Identifier
	(URI) as defined by the rule 'URI' in RFC 3986.		(URI) as defined by the rule 'URI' in RFC 3986.


	Objects using the uri type MUST be in US-ASCII encoding		Objects using the uri type MUST be in ASCII encoding
	and MUST be normalized as described in Sections 6.2.1,		and MUST be normalized as described in Sections 6.2.1,
	6.2.2.1, and 6.2.2.2 of RFC 3986. Characters that can be		6.2.2.1, and 6.2.2.2 of RFC 3986. Characters that can be
	represented without using percent-encoding are represented		represented without using percent-encoding are represented
	as characters (without percent-encoding), and all		as characters (without percent-encoding), and all
	case-insensitive characters are set to lowercase except		case-insensitive characters are set to lowercase except
	for hexadecimal digits within a percent-encoded triplet,		for hexadecimal digits within a percent-encoded triplet,
	which are normalized to uppercase as described in		which are normalized to uppercase as described in
	Section 6.2.2.1 of RFC 3986.		Section 6.2.2.1 of RFC 3986.

	The purpose of this normalization is to help provide		The purpose of this normalization is to help provide

	skipping to change at line 1738 ¶		skipping to change at line 1746 ¶
	}		}
	description		description
	"The email-address type represents an internationalized		"The email-address type represents an internationalized
	email address.		email address.

	The email address format is defined by the addr-spec		The email address format is defined by the addr-spec
	ABNF rule in Section 3.4.1 of RFC 5322. This format has		ABNF rule in Section 3.4.1 of RFC 5322. This format has
	been extended by RFC 6532 to support internationalized		been extended by RFC 6532 to support internationalized
	email addresses. Implementations MUST support the		email addresses. Implementations MUST support the
	internationalization extensions of RFC 6532. Support		internationalization extensions of RFC 6532. Support

	of the obsolete obs-local-part, obs-domain, and		for the obsolete obs-local-part, obs-domain, and
	obs-qtext parts of RFC 5322 is not required.		obs-qtext in RFC 5322 is not required.

	The domain part may use both A-labels and U-labels		The domain part may use both A-labels and U-labels
	(see RFC 5890). The canonical format of the domain part		(see RFC 5890). The canonical format of the domain part
	uses lowercase characters and U-labels (RFC 5890) where		uses lowercase characters and U-labels (RFC 5890) where
	applicable.";		applicable.";
	reference		reference
	"RFC 5322: Internet Message Format		"RFC 5322: Internet Message Format
	RFC 5890: Internationalized Domain Names in Applications		RFC 5890: Internationalized Domain Names in Applications
	(IDNA): Definitions and Document Framework		(IDNA): Definitions and Document Framework

	RFC 6531: SMTP Extension for Internationalized Email";		RFC 6532: Internationalized Email Headers";
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>

	5. IANA Considerations		5. IANA Considerations

	This document reuses the URIs for "ietf-yang-types" and "ietf-inet-		This document reuses the URIs for "ietf-yang-types" and "ietf-inet-
	types" in the "IETF XML Registry" [RFC3688].		types" in the "IETF XML Registry" [RFC3688].

	Per this document, IANA has updated the "YANG Module Names" registry		Per this document, IANA has updated the "YANG Module Names" registry

	skipping to change at line 1809 ¶		skipping to change at line 1817 ¶
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, DOI 10.17487/RFC3986, January 2005,		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	<https://www.rfc-editor.org/info/rfc3986>.		<https://www.rfc-editor.org/info/rfc3986>.

	[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and		[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
	B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,		B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
	DOI 10.17487/RFC4007, March 2005,		DOI 10.17487/RFC4007, March 2005,
	<https://www.rfc-editor.org/info/rfc4007>.		<https://www.rfc-editor.org/info/rfc4007>.


	[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
	Unique IDentifier (UUID) URN Namespace", RFC 4122,
	DOI 10.17487/RFC4122, July 2005,
	<https://www.rfc-editor.org/info/rfc4122>.

	[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing		[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 4291, DOI 10.17487/RFC4291, February		Architecture", RFC 4291, DOI 10.17487/RFC4291, February
	2006, <https://www.rfc-editor.org/info/rfc4291>.		2006, <https://www.rfc-editor.org/info/rfc4291>.

	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for		[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
	the Network Configuration Protocol (NETCONF)", RFC 6020,		the Network Configuration Protocol (NETCONF)", RFC 6020,
	DOI 10.17487/RFC6020, October 2010,		DOI 10.17487/RFC6020, October 2010,
	<https://www.rfc-editor.org/info/rfc6020>.		<https://www.rfc-editor.org/info/rfc6020>.

	[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",		[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
	RFC 7950, DOI 10.17487/RFC7950, August 2016,		RFC 7950, DOI 10.17487/RFC7950, August 2016,
	<https://www.rfc-editor.org/info/rfc7950>.		<https://www.rfc-editor.org/info/rfc7950>.

	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.


	[RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger,
	"Common YANG Data Types for the Routing Area", RFC 8294,
	DOI 10.17487/RFC8294, December 2017,
	<https://www.rfc-editor.org/info/rfc8294>.

	[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,		[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
	RFC 9499, DOI 10.17487/RFC9499, March 2024,		RFC 9499, DOI 10.17487/RFC9499, March 2024,
	<https://www.rfc-editor.org/info/rfc9499>.		<https://www.rfc-editor.org/info/rfc9499>.

	[RFC9557] Sharma, U. and C. Bormann, "Date and Time on the Internet:		[RFC9557] Sharma, U. and C. Bormann, "Date and Time on the Internet:
	Timestamps with Additional Information", RFC 9557,		Timestamps with Additional Information", RFC 9557,
	DOI 10.17487/RFC9557, April 2024,		DOI 10.17487/RFC9557, April 2024,
	<https://www.rfc-editor.org/info/rfc9557>.		<https://www.rfc-editor.org/info/rfc9557>.


			[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
			IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
			2024, <https://www.rfc-editor.org/info/rfc9562>.

	[XPATH] Clark, J., Ed. and S. DeRose, Ed., "XML Path Language		[XPATH] 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, <http://www.w3.org/TR/xpath-10>.		1999, <http://www.w3.org/TR/xpath-10>.

	[XSD-TYPES]		[XSD-TYPES]
	Peterson, D., Ed., Gao, S., Ed., Malhotra, A., Ed.,		Peterson, D., Ed., Gao, S., Ed., Malhotra, A., Ed.,
	Sperberg-McQueen, C., Ed., and H. S. Thompson, Ed., "W3C		Sperberg-McQueen, C., Ed., and H. S. Thompson, Ed., "W3C
	XML Schema Definition Language (XSD) 1.1 Part 2:		XML Schema Definition Language (XSD) 1.1 Part 2:
	Datatypes", W3C Recommendation, 5 April 2012,		Datatypes", W3C Recommendation, 5 April 2012,
	<https://www.w3.org/TR/xmlschema11-2/>.		<https://www.w3.org/TR/xmlschema11-2/>.

	skipping to change at line 2002 ¶		skipping to change at line 2004 ¶

	[RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types",		[RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types",
	RFC 6021, DOI 10.17487/RFC6021, October 2010,		RFC 6021, DOI 10.17487/RFC6021, October 2010,
	<https://www.rfc-editor.org/info/rfc6021>.		<https://www.rfc-editor.org/info/rfc6021>.

	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	and A. Bierman, Ed., "Network Configuration Protocol		and A. Bierman, Ed., "Network Configuration Protocol
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,		(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
	<https://www.rfc-editor.org/info/rfc6241>.		<https://www.rfc-editor.org/info/rfc6241>.


			[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
			Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
			2012, <https://www.rfc-editor.org/info/rfc6532>.

	[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet		[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
	Autonomous System (AS) Number Space", RFC 6793,		Autonomous System (AS) Number Space", RFC 6793,
	DOI 10.17487/RFC6793, December 2012,		DOI 10.17487/RFC6793, December 2012,
	<https://www.rfc-editor.org/info/rfc6793>.		<https://www.rfc-editor.org/info/rfc6793>.

	[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",		[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
	RFC 6991, DOI 10.17487/RFC6991, July 2013,		RFC 6991, DOI 10.17487/RFC6991, July 2013,
	<https://www.rfc-editor.org/info/rfc6991>.		<https://www.rfc-editor.org/info/rfc6991>.

	[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6

	skipping to change at line 2024 ¶		skipping to change at line 2030 ¶
	<https://www.rfc-editor.org/info/rfc8200>.		<https://www.rfc-editor.org/info/rfc8200>.

	[RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control		[RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control
	Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260,		Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260,
	June 2022, <https://www.rfc-editor.org/info/rfc9260>.		June 2022, <https://www.rfc-editor.org/info/rfc9260>.

	[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",		[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
	STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,		STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
	<https://www.rfc-editor.org/info/rfc9293>.		<https://www.rfc-editor.org/info/rfc9293>.


			[ISO-8601] ISO/IEC, "Data elements and interchange formats --
			Information interchange -- Representation of dates and
			times", ISO/IEC 8601:2000, December 2008,
			<https://www.iso.org/standard/26780.html>.

	[ISO-9834-1]		[ISO-9834-1]

	ISO/IEC, "Information technology -- Open Systems		ISO/IEC, "Information technology - Procedures for the
	Interconnection -- Procedures for the operation of OSI		operation of object identifier registration authorities -
	Registration Authorities: General procedures and top arcs		Part 1: General procedures and top arcs of the
	of the International Object Identifier tree", ISO/		international object identifier tree", ISO/
	IEC 9834-1:2008, 2008,		IEC 9834-1:2012, 2012,
	<https://www.iso.org/standard/51424.html>.		<https://www.iso.org/standard/58055.html>.


	[IEEE-802-2001]		[IEEE-802-2024]
	IEEE, "IEEE Standard for Local and Metropolitan Area		IEEE, "IEEE Standard for Local and Metropolitan Area

	Networks: Overview and Architecture", IEEE Std 802-2001,		Networks: Overview and Architecture", IEEE Std 802-2024,
	DOI 10.1109/IEEESTD.2002.93395, February 2002,		DOI 10.1109/IEEESTD.2025.10935844, March 2025,
	<https://doi.org/10.1109/IEEESTD.2002.93395>.		<https://doi.org/10.1109/IEEESTD.2025.10935844>.

	[Err4076] RFC Errata, Erratum ID 4076, RFC 6991,		[Err4076] RFC Errata, Erratum ID 4076, RFC 6991,
	<https://www.rfc-editor.org/errata/eid4076>.		<https://www.rfc-editor.org/errata/eid4076>.

	[Err5105] RFC Errata, Erratum ID 5105, RFC 6991,		[Err5105] RFC Errata, Erratum ID 5105, RFC 6991,
	<https://www.rfc-editor.org/errata/eid5105>.		<https://www.rfc-editor.org/errata/eid5105>.

	Acknowledgments		Acknowledgments

	The following people contributed significantly to the original		The following people contributed significantly to the original
	version of this document, which was published as [RFC6021]: Andy		version of this document, which was published as [RFC6021]: Andy
	Bierman, Martin Björklund, Balazs Lengyel, David Partain, and Phil		Bierman, Martin Björklund, Balazs Lengyel, David Partain, and Phil
	Shafer.		Shafer.


	Helpful comments on various versions of this document were provided		Helpful comments on various draft versions of this document were
	by the following individuals: Andy Bierman, Martin Björklund, Benoît		provided by the following individuals: Andy Bierman, Martin
	Claise, Joel M. Halpern, Ladislav Lhotka, Lars-Johan Liman, and Dan		Björklund, Benoît Claise, Joel M. Halpern, Ladislav Lhotka, Lars-
	Romascanu.		Johan Liman, and Dan Romascanu.

	Author's Address		Author's Address

	Jürgen Schönwälder (editor)		Jürgen Schönwälder (editor)
	Constructor University		Constructor University
	Email: jschoenwaelder@constructor.university		Email: jschoenwaelder@constructor.university

End of changes. 48 change blocks.
	215 lines changed or deleted		226 lines changed or added
This html diff was produced by rfcdiff 1.48.