Common YANG Data Types
Extracted elements (30)
The as-number type uses uint32 without a range restriction rather than uint16 because BGP extensions (RFC 6793) enlarged the AS number space from 16 to 32 bits. Using an unrestricted uint32 future-proofs the type against further expansion.
The date-and-time type profiles RFC 3339 rather than using the XML Schema dateTime type directly because RFC 3339 prohibits negative years, distinguishes -00:00 (unknown timezone) from +00:00/Z, uses a different full-date/full-time separator, and provides higher resolution for fractional seconds.
A default statement SHOULD NOT be used in combination with the counter32 or counter64 types, because counters have no defined initial value and a default would be semantically misleading.
Objects using the uri type MUST be in US-ASCII encoding and MUST be normalized as described by RFC 3986 Sections 6.2.1, 6.2.2.1, and 6.2.2.2 to help provide unique URIs.
The description clause of schema nodes using the domain-name type MUST describe when and how these names are resolved to IP addresses, including the order of resolution and which DNS record (A vs. AAAA) takes precedence.
The object-identifier type SHOULD NOT be used to represent SMIv2 OBJECT IDENTIFIERs; the object-identifier-128 type SHOULD be used instead, because object-identifier is a superset not restricted to the SMIv2 limit of 128 sub-identifiers.
The as-number type is a uint32 without range restriction, representing BGP Autonomous System numbers. It uses uint32 (not uint16) to accommodate the 32-bit AS number space introduced by RFC 6793, equivalent to SMIv2 InetAutonomousSystemNumber.
The counter32 type (uint32) represents a non-negative integer that monotonically increases to 2^32-1 then wraps to zero. Counters have no defined initial value, so a single value carries no information content; discontinuities should be flagged by a companion schema node. Equivalent to SMIv2 Counter32.
The counter64 type (uint64) represents a non-negative integer that monotonically increases to 2^64-1 then wraps to zero. Like counter32, it has no defined initial value and should not be used for configuration schema nodes. Equivalent to SMIv2 Counter64.
The date-and-time type is a profile of ISO 8601 using the RFC 3339 date-time production, encoded as a string matching the pattern YYYY-MM-DDTHH:MM:SS[.fraction](Z|±HH:MM). Time-offset -00:00 indicates an unknown time zone; canonical format uses a numeric UTC offset derived from the device's configured offset.
The domain-name type represents a DNS domain name of 1..253 characters in US-ASCII encoding. Internationalized domain names MUST use A-labels per RFC 5890, and schema nodes using this type MUST document how and when names are resolved to IP addresses.
The dscp type is a uint8 restricted to range 0..63 representing a Differentiated Services Code Point for marking packets in a traffic stream, equivalent to SMIv2 Dscp from DIFFSERV-DSCP-TC. The ipv6-flow-label type is a uint32 restricted to 0..1048575 for IPv6 flow discrimination.
The gauge32 and gauge64 types represent non-negative integers that may increase or decrease but are clamped to their maximum (2^32-1 or 2^64-1) and minimum (0) values. They are equivalent to SMIv2 Gauge32 and CounterBasedGauge64 respectively.
The ietf-inet-types YANG module (namespace urn:ietf:params:xml:ns:yang:ietf-inet-types) defines derived YANG data types relevant to the Internet protocol suite, including IP version, DSCP, port numbers, AS numbers, IP addresses, prefixes, domain names, and URIs. The 2013-07-15 revision adds ip-address-no-zone, ipv4-address-no-zone, and ipv6-address-no-zone.
The ietf-yang-types YANG module (namespace urn:ietf:params:xml:ns:yang:ietf-yang-types) defines a collection of generally useful derived YANG data types including counters, gauges, identifiers, date-time, address, and string types. This module obsoletes RFC 6021 and adds yang-identifier, hex-string, uuid, and dotted-quad in the 2013-07-15 revision.
The ip-address-no-zone, ipv4-address-no-zone, and ipv6-address-no-zone types (new in RFC 6991) are derived variants that prohibit zone identifiers in the address format, for use where the zone is implicit from context.
The ip-version enumeration type represents the IP protocol version with values: unknown (0), ipv4 (1), and ipv6 (2). It is equivalent to the SMIv2 InetVersion textual convention from INET-ADDRESS-MIB.
The ipv4-address type represents an IPv4 address in dotted-quad notation optionally followed by a zone index (e.g., 192.0.2.1%eth0). The ipv6-address type supports full, mixed, shortened, and shortened-mixed notation with optional zone index; canonical format follows RFC 5952 Section 4.
The ipv4-prefix and ipv6-prefix types represent CIDR prefixes as address/length strings (e.g., 192.0.2.0/24 or 2001:db8::/32). Canonical format requires all host bits not in the prefix to be zero; IPv6 canonical form additionally follows RFC 5952.
The object-identifier type represents ASN.1 OIDs as dot-separated non-negative sub-identifiers, each not exceeding 2^32-1. It is a superset of SMIv2 OBJECT IDENTIFIER since it is not restricted to 128 sub-identifiers; the object-identifier-128 type should be used for SMIv2 compatibility.
The phys-address type represents media or physical layer addresses as colon-separated pairs of hex digits (e.g., 01:23:45:67:89:ab), canonically in lowercase, equivalent to SMIv2 PhysAddress. The mac-address type is a constrained variant requiring exactly six octets for IEEE 802 MAC addresses.
The port-number type is a uint16 (0..65535) representing a 16-bit transport-layer port number assigned by IANA for UDP, TCP, DCCP, or SCTP. Port zero is reserved; schema designers can exclude it by subtyping.
The timeticks type (uint32) represents time in hundredths of a second modulo 2^32 between two epochs, equivalent to SMIv2 TimeTicks. The timestamp type derives from timeticks and records the timeticks value at which a specific occurrence happened, resetting to zero when the associated timeticks wraps.
The uri type represents a URI per STD 66 (RFC 3986) in US-ASCII encoding, normalized per RFC 3986 Sections 6.2.1, 6.2.2.1, and 6.2.2.2 (unnecessary percent-encoding removed, case-insensitive characters lowercased except hex digits which are uppercased). A zero-length URI is explicitly invalid and may express 'URI absent'.
The uuid type encodes a Universally Unique Identifier as defined by RFC 4122 in the standard 8-4-4-4-12 hex string form (e.g., f81d4fae-7dec-11d0-a765-00a0c91e6bf6), canonically lowercase. The dotted-quad type encodes an unsigned 32-bit number as four decimal octets separated by '.'.
The yang-identifier type is a string starting with an alphabetic character or underscore followed by alphanumeric characters, underscores, hyphens, or dots. It explicitly prohibits any case combination of the prefix 'xml' at the start, matching the identifier rule in RFC 6020 Section 12.
The zero-based-counter32 type derives from counter32 with a defined initial value of zero, allowing applications to use zero as a delta baseline. Applications must track the minimum wrap time to determine whether sampled deltas are valid.
RFC 6991 registers two URIs in the IETF XML registry (RFC 3688): urn:ietf:params:xml:ns:yang:ietf-yang-types and urn:ietf:params:xml:ns:yang:ietf-inet-types, both as XML namespaces with the NETMOD WG as registrant contact.
RFC 6991 registers two YANG modules in the YANG Module Names registry (RFC 6020): ietf-yang-types (prefix: yang) and ietf-inet-types (prefix: inet), both with their respective namespace URIs and RFC 6991 as the reference.
The common data type definitions themselves have no direct security impact on the Internet. However, the usage of these definitions in concrete YANG modules might introduce security implications, and the security considerations of the YANG specification (RFC 6020) apply to any module using these types.