Common YANG Data Types
obsoletes
- rfc-6991 — Common YANG Data Types
Extracted elements (30)
The date-and-time canonical format uses Z for UTC with unknown local timezone and +00:00 for UTC with a known UTC reference point, aligning with RFC 9557 Section 2. This distinction was not present in earlier versions and breaks SMIv2 DateAndTime equivalence because RFC 3339 uses 'T' as the date/time separator rather than a comma.
The host union type was changed in RFC 9911 to use host-name instead of domain-name. This is because host names follow stricter syntax rules (RFC 952) than generic DNS domain names, and schema nodes representing host names should use the more restrictive type.
The object-identifier type is a superset of the SMIv2 OBJECT IDENTIFIER type (no 128 sub-identifier limit) and SHOULD NOT be used to represent SMIv2 OBJECT IDENTIFIER; instead, object-identifier-128 SHOULD be used. This preserves strict SMIv2 equivalence while allowing extensibility for non-SMIv2 contexts.
RFC 9911 addresses Erratum ID 4076 and Erratum ID 5105 against RFC 6991, in addition to updating the yang-identifier definition to YANG 1.1 rules and improving various pattern statements and descriptions.
Several types have defined equivalences to SMIv2 types (e.g., counter32 ↔ Counter32, gauge32 ↔ Gauge32, timeticks ↔ TimeTicks, mac-address ↔ MacAddress, port-number ↔ InetPortNumber). The date-and-time type is explicitly NOT equivalent to SMIv2 DateAndTime due to different date/time separators and higher time-secfrac resolution.
A default statement SHOULD NOT be used in combination with counter32 or counter64 types, and these types should not be used for configuration schema nodes.
Implementations of the email-address type MUST support the internationalization extensions of RFC 6532; support for the obsolete obs-local-part, obs-domain, and obs-qtext productions in RFC 5322 is not required.
Objects using the uri type MUST be in ASCII encoding and MUST be normalized as described in RFC 3986 Sections 6.2.1, 6.2.2.1, and 6.2.2.2, with case-insensitive characters set to lowercase (except percent-encoded hex digits, which are normalized to uppercase).
Schema nodes using the xpath1.0 type MUST specify the XPath context in which the expression is evaluated in their description clause.
The description clause of schema nodes using domain-name MUST describe when and how names are resolved to IP addresses. Internationalized domain names used with this type MUST be A-labels per RFC 5890.
RFC 9911 introduces four new date/time scalar types: 'date' (date interval with optional timezone), 'date-no-zone' (date without timezone), 'time' (daily recurrent time with optional timezone, allowing leap second value 60), and 'time-no-zone' (time without timezone). All are string types with regex patterns aligned to RFC 3339 and RFC 9557.
RFC 9911 introduces ip-address-and-prefix, ipv4-address-and-prefix, and ipv6-address-and-prefix types. Unlike ip-prefix types, these retain the full interface address alongside the prefix length, making them suitable for interface address modeling.
RFC 9911 introduces ip-address-link-local, ipv4-address-link-local (restricted to 169.254.0.0/16 per RFC 3927), and ipv6-address-link-local (restricted to fe80::/10 per RFC 4291) types for modeling link-local addresses specifically.
RFC 9911 introduces nine new duration types: hours32 (int32), minutes32 (int32), seconds32 (int32), centiseconds32 (int32), milliseconds32 (int32), microseconds32 (int32), microseconds64 (int64), nanoseconds32 (int32), and nanoseconds64 (int64). All represent signed time periods in their respective units and should be range-restricted to '0..max' when only non-negative values are needed.
RFC 9911 introduces protocol-number (uint8) representing the 8-bit IP protocol field (IPv4 'protocol' or IPv6 'next header'), and upper-layer-protocol-number (derived from protocol-number) representing the final protocol number in an IPv6 extension header chain.
RFC 9911 introduces the email-address type (string with pattern '.+@.+') representing internationalized email addresses per RFC 5322 extended by RFC 6532. The domain part supports both A-labels and U-labels; canonical format uses lowercase and U-labels.
The counter32 type (uint32 base) and counter64 type (uint64 base) represent monotonically increasing non-negative integers that wrap around to zero upon reaching their maximum values (2^32-1 and 2^64-1 respectively). Counters have no defined initial value; discontinuities must be indicated by a companion schema node.
The date-and-time type is a string profiling ISO 8601 / RFC 3339 with the RFC 9557 update. It allows leap seconds (value 60 for seconds), and distinguishes UTC with unknown local timezone (Z) from UTC with known UTC reference point (+00:00). The type is not equivalent to the SMIv2 DateAndTime textual convention.
The domain-name type (string, 1..253 characters) models DNS domain names with a pattern permitting current practices. The host-name type, new in RFC 9911, is a stricter subtype (2..max, letters/digits/hyphens/dots only) for fully qualified host names per RFC 952 and RFC 1123. The host union was updated to use host-name instead of domain-name.
The gauge32 type (uint32) and gauge64 type (uint64) represent non-negative integers that may increase or decrease but are clamped at their maximum and minimum values. They are equivalent to the SMIv2 Gauge32 and CounterBasedGauge64 types.
The 'ietf-inet-types' module defines YANG data types for Internet Protocol suite concepts including IP addresses, prefixes, port numbers, protocol numbers, domain names, URIs, and email addresses. It is published under the namespace urn:ietf:params:xml:ns:yang:ietf-inet-types with prefix 'inet'.
The 'ietf-yang-types' module defines generally useful derived YANG data types including counters, gauges, date/time types, physical addresses, UUIDs, and language tags. It is published under the namespace urn:ietf:params:xml:ns:yang:ietf-yang-types with prefix 'yang'.
The ip-address-no-zone, ipv4-address-no-zone, and ipv6-address-no-zone types restrict the corresponding address types to exclude zone identifiers. These are used when the zone is determined by context and embedding it in the value would be redundant.
The ipv4-address and ipv6-address types represent IP addresses in dotted-quad and compressed hex notation respectively, both supporting optional zone identifiers separated by a '%' sign. The ip-address union type is version-neutral, inferring version from textual format.
The ipv4-prefix and ipv6-prefix types encode IP prefixes in address/length notation. Implementations MUST return values in canonical format with non-prefix bits set to zero (e.g., 192.0.2.1/24 is accepted but returned as 192.0.2.0/24).
The language-tag type (string) represents BCP 47 / RFC 5646 language tags; values MUST be well-formed and implementations MAY further restrict to 'validating' tags. The canonical representation uses lowercase characters, aligned with the SMIv2 LangTag textual convention.
The timeticks type (uint32) represents time in hundredths of a second between two epochs modulo 2^32. The timestamp type (derived from timeticks) records the timeticks value at which a specific occurrence happened; it resets to zero when the associated timeticks instance wraps.
The yang-identifier type is a string restricted to identifiers starting with a letter or underscore, followed by letters, digits, underscores, hyphens, or dots (per YANG 1.1 Section 14 of RFC 7950). The RFC 6991 restriction excluding identifiers beginning with 'xml' (required by YANG 1.0) has been removed, though it still applies in YANG 1 contexts.
IANA updated the 'YANG Module Names' registry to reference RFC 9911 (replacing RFC 6991) for the 'ietf-yang-types' module (namespace urn:ietf:params:xml:ns:yang:ietf-yang-types, prefix 'yang') and the 'ietf-inet-types' module (namespace urn:ietf:params:xml:ns:yang:ietf-inet-types, prefix 'inet'). The IETF XML Registry URIs are reused.
The type definitions themselves have no direct security impact on the Internet. However, the security considerations of RFC 7950 (YANG 1.1) apply, since the usage of these types in concrete YANG modules accessed via NETCONF or RESTCONF may expose sensitive network configuration data.