diff --git a/experimental/ietf-extracted-YANG-modules/ietf-inet-types@2025-06-23.yang b/experimental/ietf-extracted-YANG-modules/ietf-inet-types@2025-06-23.yang deleted file mode 100644 index b28621b9f..000000000 --- a/experimental/ietf-extracted-YANG-modules/ietf-inet-types@2025-06-23.yang +++ /dev/null @@ -1,669 +0,0 @@ -module ietf-inet-types { - - namespace "urn:ietf:params:xml:ns:yang:ietf-inet-types"; - prefix "inet"; - - organization - "IETF Network Modeling (NETMOD) Working Group"; - - contact - "WG Web: - WG List: - - Editor: Juergen Schoenwaelder - "; - - description - "This module contains a collection of generally useful derived - YANG data types for Internet addresses and related things. - - The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL - NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', - 'MAY', and 'OPTIONAL' in this document are to be interpreted as - described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, - they appear in all capitals, as shown here. - - Copyright (c) 2025 IETF Trust and the persons identified as - authors of the code. All rights reserved. - - Redistribution and use in source and binary forms, with or - without modification, is permitted pursuant to, and subject - to the license terms contained in, the Revised BSD License - set forth in Section 4.c of the IETF Trust's Legal Provisions - Relating to IETF Documents - (https://trustee.ietf.org/license-info). - - This version of this YANG module is part of RFC XXXX; - see the RFC itself for full legal notices."; - - revision 2025-06-23 { - description - "This revision adds the following new data types: - - inet:ip-address-and-prefix - - inet:ipv4-address-and-prefix - - inet:ipv6-address-and-prefix - - inet:protocol-number - - inet:upper-layer-protocol-number - - inet:host-name - - inet:email-address - - inet:ip-address-link-local - - inet:ipv4-address-link-local - - inet:ipv6-address-link-local - The inet:host union was changed to use inet:host-name instead - of inet:domain-name. Several pattern statements have been - improved."; - reference - "RFC XXXX: Common YANG Data Types"; - } - - revision 2013-07-15 { - description - "This revision adds the following new data types: - - inet:ip-address-no-zone - - inet:ipv4-address-no-zone - - inet:ipv6-address-no-zone"; - reference - "RFC 6991: Common YANG Data Types"; - } - - revision 2010-09-24 { - description - "Initial revision."; - reference - "RFC 6021: Common YANG Data Types"; - } - - /*** collection of types related to protocol fields ***/ - - typedef ip-version { - type enumeration { - enum unknown { - value "0"; - description - "An unknown or unspecified version of the Internet - protocol."; - } - enum ipv4 { - value "1"; - description - "The IPv4 protocol as defined in RFC 791."; - } - enum ipv6 { - value "2"; - description - "The IPv6 protocol as defined in RFC 8200."; - } - } - description - "This value represents the version of the IP protocol. - - In the value set and its semantics, this type is equivalent - to the InetVersion textual convention of the SMIv2."; - reference - "RFC 791: Internet Protocol - RFC 8200: Internet Protocol, Version 6 (IPv6) Specification - RFC 4001: Textual Conventions for Internet Network Addresses"; - } - - typedef dscp { - type uint8 { - range "0..63"; - } - description - "The dscp type represents a Differentiated Services Code Point - that may be used for marking packets in a traffic stream. - - In the value set and its semantics, this type is equivalent - to the Dscp textual convention of the SMIv2."; - reference - "RFC 3289: Management Information Base for the Differentiated - Services Architecture - RFC 2474: Definition of the Differentiated Services Field - (DS Field) in the IPv4 and IPv6 Headers - RFC 2780: IANA Allocation Guidelines For Values In - the Internet Protocol and Related Headers"; - } - - typedef ipv6-flow-label { - type uint32 { - range "0..1048575"; - } - description - "The ipv6-flow-label type represents the flow identifier or - Flow Label in an IPv6 packet header that may be used to - discriminate traffic flows. - - In the value set and its semantics, this type is equivalent - to the IPv6FlowLabel textual convention of the SMIv2."; - reference - "RFC 3595: Textual Conventions for IPv6 Flow Label - RFC 8200: Internet Protocol, Version 6 (IPv6) Specification"; - } - - typedef port-number { - type uint16 { - range "0..65535"; - } - description - "The port-number type represents a 16-bit port number of an - Internet transport-layer protocol such as UDP, TCP, DCCP, or - SCTP. - - Port numbers are assigned by IANA. The current list of - all assignments is available from . - - Note that the port number value zero is reserved by IANA. In - situations where the value zero does not make sense, it can - be excluded by subtyping the port-number type. - - In the value set and its semantics, this type is equivalent - to the InetPortNumber textual convention of the SMIv2."; - reference - "RFC 768: User Datagram Protocol - RFC 9293: Transmission Control Protocol (TCP) - RFC 9260: Stream Control Transmission Protocol - RFC 4340: Datagram Congestion Control Protocol (DCCP) - RFC 4001: Textual Conventions for Internet Network Addresses"; - } - - typedef protocol-number { - type uint8; - description - "The protocol-number type represents an 8-bit Internet - protocol number, carried in the 'protocol' field of the - IPv4 header or in the 'next header' field of the IPv6 - header. - - Protocol numbers are assigned by IANA. The current list of - all assignments is available from ."; - reference - "RFC 791: Internet Protocol - RFC 8200: Internet Protocol, Version 6 (IPv6) Specification"; - } - - typedef upper-layer-protocol-number { - type protocol-number; - description - "The upper-layer-protocol-number represents the upper-layer - protocol number carried in an IP packet. For IPv6 packets - with extension headers, this is the protocol number carried - in the last 'next header' field of the chain of IPv6 extension - headers."; - reference - "RFC 791: Internet Protocol - RFC 8200: Internet Protocol, Version 6 (IPv6) Specification"; - } - - /*** collection of types related to autonomous systems ***/ - - typedef as-number { - type uint32; - description - "The as-number type represents autonomous system numbers - which identify an Autonomous System (AS). An AS is a set - of routers under a single technical administration, using - an interior gateway protocol and common metrics to route - packets within the AS, and using an exterior gateway - protocol to route packets to other ASes. IANA maintains - the AS number space and has delegated large parts to the - regional registries. - - Autonomous system numbers were originally limited to 16 - bits. BGP extensions have enlarged the autonomous system - number space to 32 bits. This type therefore uses an uint32 - base type without a range restriction in order to support - a larger autonomous system number space. - - In the value set and its semantics, this type is equivalent - to the InetAutonomousSystemNumber textual convention of - the SMIv2."; - reference - "RFC 1930: Guidelines for creation, selection, and registration - of an Autonomous System (AS) - RFC 4271: A Border Gateway Protocol 4 (BGP-4) - RFC 4001: Textual Conventions for Internet Network Addresses - RFC 6793: BGP Support for Four-Octet Autonomous System (AS) - Number Space"; - } - - /*** collection of types related to IP addresses and hostnames ***/ - - typedef ip-address { - type union { - type ipv4-address; - type ipv6-address; - } - description - "The ip-address type represents an IP address and is IP - version neutral. The format of the textual representation - implies the IP version. This type supports scoped addresses - by allowing zone identifiers in the address format."; - reference - "RFC 4007: IPv6 Scoped Address Architecture"; - } - - typedef ipv4-address { - type string { - 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])' - + '(%.+)?'; - } - description - "The ipv4-address type represents an IPv4 address in - dotted-quad notation. The IPv4 address may include a zone - index, separated by a % sign. If a system uses zone names - that are not represented in UTF-8, then an implementation - needs to use some mechanism to transform the local name - into UTF-8. The definition of such a mechanism is outside - the scope of this document. - - The zone index is used to disambiguate identical address - values. For link-local addresses, the zone index will - typically be the interface index number or the name of an - interface. If the zone index is not present, the default - zone of the device will be used. - - The canonical format for the zone index is the numerical - format"; - } - - typedef ipv6-address { - type string { - pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' - + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' - + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' - + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' - + '(%[A-Za-z0-9][A-Za-z0-9\-\._~/]*)?'; - pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' - + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' - + '(%.+)?'; - } - description - "The ipv6-address type represents an IPv6 address in full, - mixed, shortened, and shortened-mixed notation. The IPv6 - address may include a zone index, separated by a % sign. - If a system uses zone names that are not represented in - UTF-8, then an implementation needs to use some mechanism - to transform the local name into UTF-8. The definition of - such a mechanism is outside the scope of this document. - - The zone index is used to disambiguate identical address - values. For link-local addresses, the zone index will - typically be the interface index number or the name of an - interface. If the zone index is not present, the default - zone of the device will be used. - - The canonical format of IPv6 addresses uses the textual - representation defined in Section 4 of RFC 5952. The - canonical format for the zone index is the numerical - format as described in Section 11.2 of RFC 4007."; - reference - "RFC 4291: IP Version 6 Addressing Architecture - RFC 4007: IPv6 Scoped Address Architecture - RFC 5952: A Recommendation for IPv6 Address Text - Representation"; - } - - typedef ip-address-no-zone { - type union { - type ipv4-address-no-zone; - type ipv6-address-no-zone; - } - description - "The ip-address-no-zone type represents an IP address and is - IP version neutral. The format of the textual representation - implies the IP version. This type does not support scoped - addresses since it does not allow zone identifiers in the - address format."; - reference - "RFC 4007: IPv6 Scoped Address Architecture"; - } - - typedef ipv4-address-no-zone { - type ipv4-address { - pattern '[0-9\.]*'; - } - description - "An IPv4 address without a zone index. This type, derived - from the type ipv4-address, may be used in situations where - the zone is known from the context and no zone index is - needed."; - } - - typedef ipv6-address-no-zone { - type ipv6-address { - pattern '[0-9a-fA-F:\.]*'; - } - description - "An IPv6 address without a zone index. This type, derived - from the type ipv6-address, may be used in situations where - the zone is known from the context and no zone index is - needed."; - reference - "RFC 4291: IP Version 6 Addressing Architecture - RFC 4007: IPv6 Scoped Address Architecture - RFC 5952: A Recommendation for IPv6 Address Text - Representation"; - } - - typedef ip-address-link-local { - type union { - type ipv4-address-link-local; - type ipv6-address-link-local; - } - description - "The ip-address-link-local type represents a link-local IP - address and is IP version neutral. The format of the textual - representation implies the IP version."; - } - - typedef ipv4-address-link-local { - type ipv4-address { - pattern '169\.254\..*'; - } - description - "A link-local IPv4 address in the prefix 169.254.0.0/16 as - defined in section 2.1. of RFC 3927."; - reference - "RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses"; - } - - typedef ipv6-address-link-local { - type ipv6-address { - pattern '[fF][eE]80:.*'; - } - description - "A link-local IPv6 address in the prefix fe80::/10 as defined - in section 2.5.6. of RFC 4291."; - reference - "RFC 4291: IP Version 6 Addressing Architecture"; - } - - typedef ip-prefix { - type union { - type ipv4-prefix; - type ipv6-prefix; - } - description - "The ip-prefix type represents an IP prefix and is IP - version neutral. The format of the textual representations - implies the IP version."; - } - - typedef ipv4-prefix { - type string { - 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])' - + '/(([0-9])|([1-2][0-9])|(3[0-2]))'; - } - description - "The ipv4-prefix type represents an IPv4 prefix. - The prefix length is given by the number following the - slash character and must be less than or equal to 32. - - A prefix length value of n corresponds to an IP address - mask that has n contiguous 1-bits from the most - significant bit (MSB) and all other bits set to 0. - - The canonical format of an IPv4 prefix has all bits of - the IPv4 address set to zero that are not part of the - IPv4 prefix. - - The definition of ipv4-prefix does not require that bits, - which are not part of the prefix, are set to zero. However, - implementations have to return values in canonical format, - which requires non-prefix bits to be set to zero. This means - that 192.0.2.1/24 must be accepted as a valid value but it - will be converted into the canonical format 192.0.2.0/24."; - } - - typedef ipv6-prefix { - type string { - pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' - + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' - + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' - + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' - + '(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))'; - pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' - + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' - + '(/.+)'; - } - description - "The ipv6-prefix type represents an IPv6 prefix. - The prefix length is given by the number following the - slash character and must be less than or equal to 128. - - A prefix length value of n corresponds to an IP address - mask that has n contiguous 1-bits from the most - significant bit (MSB) and all other bits set to 0. - - The canonical format of an IPv6 prefix has all bits of - the IPv6 address set to zero that are not part of the - IPv6 prefix. Furthermore, the IPv6 address is represented - as defined in Section 4 of RFC 5952. - - The definition of ipv6-prefix does not require that bits, - which are not part of the prefix, are set to zero. However, - implementations have to return values in canonical format, - which requires non-prefix bits to be set to zero. This means - that 2001:db8::1/64 must be accepted as a valid value but it - will be converted into the canonical format 2001:db8::/64."; - reference - "RFC 5952: A Recommendation for IPv6 Address Text - Representation"; - } - - typedef ip-address-and-prefix { - type union { - type ipv4-address-and-prefix; - type ipv6-address-and-prefix; - } - description - "The ip-address-and-prefix type represents an IP address and - prefix and is IP version neutral. The format of the textual - representations implies the IP version."; - } - - typedef ipv4-address-and-prefix { - type string { - 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])' - + '/(([0-9])|([1-2][0-9])|(3[0-2]))'; - } - description - "The ipv4-address-and-prefix type represents an IPv4 - address and an associated IPv4 prefix. - The prefix length is given by the number following the - slash character and must be less than or equal to 32. - - A prefix length value of n corresponds to an IP address - mask that has n contiguous 1-bits from the most - significant bit (MSB) and all other bits set to 0."; - } - - typedef ipv6-address-and-prefix { - type string { - pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' - + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' - + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' - + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' - + '(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))'; - pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' - + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' - + '(/.+)'; - } - description - "The ipv6-address-and-prefix type represents an IPv6 - address and an associated IPv6 prefix. - The prefix length is given by the number following the - slash character and must be less than or equal to 128. - - A prefix length value of n corresponds to an IP address - mask that has n contiguous 1-bits from the most - significant bit (MSB) and all other bits set to 0. - - The canonical format requires that the IPv6 address is - represented as defined in Section 4 of RFC 5952."; - reference - "RFC 5952: A Recommendation for IPv6 Address Text - Representation"; - } - - /*** collection of domain name and URI types ***/ - - typedef domain-name { - type string { - length "1..253"; - 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]\.?)' - + '|\.'; - } - description - "The domain-name type represents a DNS domain name. The - name SHOULD be fully qualified whenever possible. This - type does not support wildcards (see RFC 4592) or - classless in-addr.arpa delegations (see RFC 2317). - - Internet domain names are only loosely specified. Section - 3.5 of RFC 1034 recommends a syntax (modified in Section - 2.1 of RFC 1123). The pattern above is intended to allow - for current practice in domain name use, and some possible - future expansion. Note that Internet host names have a - stricter syntax (described in RFC 952) than the DNS - recommendations in RFCs 1034 and 1123. Schema nodes - representing host names should use the host-name type - instead of the domain-type. - - The encoding of DNS names in the DNS protocol is limited - to 255 characters. Since the encoding consists of labels - prefixed by a length bytes and there is a trailing NULL - byte, only 253 characters can appear in the textual dotted - notation. - - The description clause of schema nodes using the domain-name - type MUST describe when and how these names are resolved to - IP addresses. Note that the resolution of a domain-name value - may require to query multiple DNS records (e.g., A for IPv4 - and AAAA for IPv6). The order of the resolution process and - which DNS record takes precedence can either be defined - explicitly or may depend on the configuration of the - resolver. - - Domain-name values use the US-ASCII encoding. Their canonical - format uses lowercase US-ASCII characters. Internationalized - domain names MUST be A-labels as per RFC 5890."; - reference - "RFC 952: DoD Internet Host Table Specification - RFC 1034: Domain Names - Concepts and Facilities - RFC 1123: Requirements for Internet Hosts -- Application - and Support - RFC 2317: Classless IN-ADDR.ARPA delegation - RFC 2782: A DNS RR for specifying the location of services - (DNS SRV) - RFC 4592: The Role of Wildcards in the Domain Name System - RFC 5890: Internationalized Domain Names in Applications - (IDNA): Definitions and Document Framework - RFC 9499: DNS Terminology"; - } - - typedef host-name { - type domain-name { - length "2..max"; - pattern '[a-zA-Z0-9\-\.]+'; - } - description - "The host-name type represents (fully qualified) host names. - Host names must be at least two characters long (see RFC 952) - and they are restricted to labels consisting of letters, digits - and hyphens separated by dots (see RFC1123 and RFC 952)."; - reference - "RFC 952: DoD Internet Host Table Specification - RFC 1123: Requirements for Internet Hosts -- Application - and Support"; - } - - typedef host { - type union { - type ip-address; - type host-name; - } - description - "The host type represents either an IP address or a (fully - qualified) host name."; - } - - typedef uri { - type string { - pattern '[a-z][a-z0-9+.-]*:.*'; - } - description - "The uri type represents a Uniform Resource Identifier - (URI) as defined by the rule 'URI' in RFC 3986. - - 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. Characters that can be - represented without using percent-encoding are represented - as characters (without percent-encoding), and all - case-insensitive characters are set to lowercase except - for hexadecimal digits within a percent-encoded triplet, - which are normalized to uppercase as described in - Section 6.2.2.1 of RFC 3986. - - The purpose of this normalization is to help provide - unique URIs. Note that this normalization is not - sufficient to provide uniqueness. Two URIs that are - textually distinct after this normalization may still be - equivalent. - - Objects using the uri type may restrict the schemes that - they permit. For example, 'data:' and 'urn:' schemes - might not be appropriate. - - A zero-length URI is not a valid URI. This can be used to - express 'URI absent' where required. - - In the value set and its semantics, this type is equivalent - to the Uri SMIv2 textual convention defined in RFC 5017."; - reference - "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax - RFC 3305: Report from the Joint W3C/IETF URI Planning Interest - Group: Uniform Resource Identifiers (URIs), URLs, - and Uniform Resource Names (URNs): Clarifications - and Recommendations - RFC 5017: MIB Textual Conventions for Uniform Resource - Identifiers (URIs)"; - } - - typedef email-address { - type string { - pattern '.+@.+'; - } - description - "The email-address type represents an internationalized - email address. - - The email address format is defined by the addr-spec - ABNF rule in RFC 5322 section 3.4.1. This format has - been extended by RFC 6532 to support internationalized - email addresses. Implementations MUST support the - internationalization extensions of RFC 6532. Support - of the obsolete obs-local-part, obs-domain, and - obs-qtext parts of RFC 5322 is not required. - - The domain part may use both A-labels and U-labels - (see RFC 5890). The canonical format of the domain part - uses lowercase characters and U-labels (RFC 5890) where - applicable."; - reference - "RFC 5322: Internet Message Format - RFC 5890: Internationalized Domain Names in Applications - (IDNA): Definitions and Document Framework - RFC 6531: SMTP Extension for Internationalized Email"; - } - -} \ No newline at end of file diff --git a/experimental/ietf-extracted-YANG-modules/ietf-yang-types@2025-06-23.yang b/experimental/ietf-extracted-YANG-modules/ietf-yang-types@2025-06-23.yang deleted file mode 100644 index b125a1691..000000000 --- a/experimental/ietf-extracted-YANG-modules/ietf-yang-types@2025-06-23.yang +++ /dev/null @@ -1,761 +0,0 @@ -module ietf-yang-types { - - namespace "urn:ietf:params:xml:ns:yang:ietf-yang-types"; - prefix "yang"; - - organization - "IETF Network Modeling (NETMOD) Working Group"; - - contact - "WG Web: - WG List: - - Editor: Juergen Schoenwaelder - "; - - description - "This module contains a collection of generally useful derived - YANG data types. - - The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL - NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', - 'MAY', and 'OPTIONAL' in this document are to be interpreted as - described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, - they appear in all capitals, as shown here. - - Copyright (c) 2025 IETF Trust and the persons identified as - authors of the code. All rights reserved. - - Redistribution and use in source and binary forms, with or - without modification, is permitted pursuant to, and subject - to the license terms contained in, the Revised BSD License - set forth in Section 4.c of the IETF Trust's Legal Provisions - Relating to IETF Documents - (https://trustee.ietf.org/license-info). - - This version of this YANG module is part of RFC XXXX; - see the RFC itself for full legal notices."; - - revision 2025-06-23 { - description - "This revision adds the following new data types: - - yang:date - - yang:date-no-zone - - yang:time - - yang:time-no-zone - - yang:hours32 - - yang:minutes32 - - yang:seconds32 - - yang:centiseconds32 - - yang:milliseconds32 - - yang:microseconds32 - - yang:microseconds64 - - yang:nanoseconds32 - - yang:nanoseconds64 - - yang:language-tag - The yang-identifier definition has been aligned with YANG - 1.1 and types representing time support the representation - of leap seconds. The representation of time zone offsets - has been aligned with RFC 9557. Several description and - pattern statements have been improved."; - reference - "RFC XXXX: Common YANG Data Types"; - } - - revision 2013-07-15 { - description - "This revision adds the following new data types: - - yang:yang-identifier - - yang:hex-string - - yang:uuid - - yang:dotted-quad"; - reference - "RFC 6991: Common YANG Data Types"; - } - - revision 2010-09-24 { - description - "Initial revision."; - reference - "RFC 6021: Common YANG Data Types"; - } - - /*** collection of counter and gauge types ***/ - - typedef counter32 { - type uint32; - description - "The counter32 type represents a non-negative integer - that monotonically increases until it reaches a - maximum value of 2^32-1 (4294967295 decimal), when it - wraps around and starts increasing again from zero. - - Counters have no defined 'initial' value, and thus, a - single value of a counter has (in general) no information - content. Discontinuities in the monotonically increasing - value normally occur at re-initialization of the - management system, and at other times as specified in the - description of a schema node using this type. If such - other times can occur, for example, the instantiation of - a schema node of type counter32 at times other than - re-initialization, then a corresponding schema node - should be defined, with an appropriate type, to indicate - the last discontinuity. - - The counter32 type should not be used for configuration - schema nodes. A default statement SHOULD NOT be used in - combination with the type counter32. - - In the value set and its semantics, this type is equivalent - to the Counter32 type of the SMIv2."; - reference - "RFC 2578: Structure of Management Information Version 2 - (SMIv2)"; - } - - typedef zero-based-counter32 { - type counter32; - default "0"; - description - "The zero-based-counter32 type represents a counter32 - that has the defined 'initial' value zero. - - A data tree node using this type will be set to zero (0) - on creation and will thereafter increase monotonically until - it reaches a maximum value of 2^32-1 (4294967295 decimal), - when it wraps around and starts increasing again from zero. - - Provided that an application discovers a new data tree node - using this type within the minimum time to wrap, it can use - the 'initial' value as a delta. It is important for a - management station to be aware of this minimum time and the - actual time between polls, and to discard data if the actual - time is too long or there is no defined minimum time. - - In the value set and its semantics, this type is equivalent - to the ZeroBasedCounter32 textual convention of the SMIv2."; - reference - "RFC 4502: Remote Network Monitoring Management Information - Base Version 2"; - } - - typedef counter64 { - type uint64; - description - "The counter64 type represents a non-negative integer - that monotonically increases until it reaches a - maximum value of 2^64-1 (18446744073709551615 decimal), - when it wraps around and starts increasing again from zero. - - Counters have no defined 'initial' value, and thus, a - single value of a counter has (in general) no information - content. Discontinuities in the monotonically increasing - value normally occur at re-initialization of the - management system, and at other times as specified in the - description of a schema node using this type. If such - other times can occur, for example, the instantiation of - a schema node of type counter64 at times other than - re-initialization, then a corresponding schema node - should be defined, with an appropriate type, to indicate - the last discontinuity. - - The counter64 type should not be used for configuration - schema nodes. A default statement SHOULD NOT be used in - combination with the type counter64. - - In the value set and its semantics, this type is equivalent - to the Counter64 type of the SMIv2."; - reference - "RFC 2578: Structure of Management Information Version 2 - (SMIv2)"; - } - - typedef zero-based-counter64 { - type counter64; - default "0"; - description - "The zero-based-counter64 type represents a counter64 that - has the defined 'initial' value zero. - - A data tree node using this type will be set to zero (0) - on creation and will thereafter increase monotonically until - it reaches a maximum value of 2^64-1 (18446744073709551615 - decimal), when it wraps around and starts increasing again - from zero. - - Provided that an application discovers a new data tree node - using this type within the minimum time to wrap, it can use - the 'initial' value as a delta. It is important for a - management station to be aware of this minimum time and the - actual time between polls, and to discard data if the actual - time is too long or there is no defined minimum time. - - In the value set and its semantics, this type is equivalent - to the ZeroBasedCounter64 textual convention of the SMIv2."; - reference - "RFC 2856: Textual Conventions for Additional High Capacity - Data Types"; - } - - typedef gauge32 { - type uint32; - description - "The gauge32 type represents a non-negative integer, which - may increase or decrease, but shall never exceed a maximum - value, nor fall below a minimum value. The maximum value - cannot be greater than 2^32-1 (4294967295 decimal), and - the minimum value cannot be smaller than 0. The value of - a gauge32 has its maximum value whenever the information - being modeled is greater than or equal to its maximum - value, and has its minimum value whenever the information - being modeled is smaller than or equal to its minimum value. - If the information being modeled subsequently decreases - below (increases above) the maximum (minimum) value, the - gauge32 also decreases (increases). - - In the value set and its semantics, this type is equivalent - to the Gauge32 type of the SMIv2."; - reference - "RFC 2578: Structure of Management Information Version 2 - (SMIv2)"; - } - - typedef gauge64 { - type uint64; - description - "The gauge64 type represents a non-negative integer, which - may increase or decrease, but shall never exceed a maximum - value, nor fall below a minimum value. The maximum value - cannot be greater than 2^64-1 (18446744073709551615), and - the minimum value cannot be smaller than 0. The value of - a gauge64 has its maximum value whenever the information - being modeled is greater than or equal to its maximum - value, and has its minimum value whenever the information - being modeled is smaller than or equal to its minimum value. - If the information being modeled subsequently decreases - below (increases above) the maximum (minimum) value, the - gauge64 also decreases (increases). - - In the value set and its semantics, this type is equivalent - to the CounterBasedGauge64 SMIv2 textual convention defined - in RFC 2856"; - reference - "RFC 2856: Textual Conventions for Additional High Capacity - Data Types"; - } - - /*** collection of identifier-related types ***/ - - typedef object-identifier { - type string { - pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9][0-9]*))))' - + '(\.(0|([1-9][0-9]*)))*'; - } - description - "The object-identifier type represents administratively - assigned names in a registration-hierarchical-name tree. - - Values of this type are denoted as a sequence of numerical - non-negative sub-identifier values. Each sub-identifier - value MUST NOT exceed 2^32-1 (4294967295). Sub-identifiers - are separated by single dots and without any intermediate - whitespace. - - The ASN.1 standard restricts the value space of the first - sub-identifier to 0, 1, or 2. Furthermore, the value space - of the second sub-identifier is restricted to the range - 0 to 39 if the first sub-identifier is 0 or 1. Finally, - the ASN.1 standard requires that an object identifier - has always at least two sub-identifiers. The pattern - captures these restrictions. - - Although the number of sub-identifiers is not limited, - module designers should realize that there may be - implementations that stick with the SMIv2 limit of 128 - sub-identifiers. - - This type is a superset of the SMIv2 OBJECT IDENTIFIER type - since it is not restricted to 128 sub-identifiers. Hence, - this type SHOULD NOT be used to represent the SMIv2 OBJECT - IDENTIFIER type; the object-identifier-128 type SHOULD be - used instead."; - reference - "ISO9834-1: Information technology -- Open Systems - Interconnection -- Procedures for the operation of OSI - Registration Authorities: General procedures and top - arcs of the ASN.1 Object Identifier tree"; - } - - typedef object-identifier-128 { - type object-identifier { - pattern '[0-9]*(\.[0-9]*){1,127}'; - } - description - "This type represents object-identifiers restricted to 128 - sub-identifiers. - - In the value set and its semantics, this type is equivalent - to the OBJECT IDENTIFIER type of the SMIv2."; - reference - "RFC 2578: Structure of Management Information Version 2 - (SMIv2)"; - } - - /*** collection of types related to date and time ***/ - - typedef date-and-time { - type string { - pattern - '[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]+)?' - + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; - } - description - "The date-and-time type is a profile of the ISO 8601 - standard for representation of dates and times using the - Gregorian calendar. The profile is defined by the - date-time production in Section 5.6 of RFC 3339 and the - update defined in Section 2 of RFC 9557 . The value of - 60 for seconds is allowed only in the case of leap seconds. - - The date-and-time type is compatible with the dateTime XML - schema dateTime type with the following notable exceptions: - - (a) The date-and-time type does not allow negative years. - - (b) The time-offset Z indicates that the date-and-time - value is reported in UTC and that the local time zone - reference point is unknown. The time-offsets +00:00 - indicates that the date-and-time value is reported in - UTC and that the local time reference point is UTC - (see RFC 9557 section 2). - - This type is not equivalent to the DateAndTime textual - convention of the SMIv2 since RFC 3339 uses a different - separator between full-date and full-time and provides - higher resolution of time-secfrac. - - The canonical format for date-and-time values with a known time - 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 offset to UTC time will cause date-and-time values - to change accordingly. Such changes might happen periodically - in case a server follows automatically daylight saving time - (DST) time zone offset changes. The canonical format for - date-and-time values reported in UTC with an unknown local - time zone offset SHOULD use the time-offset Z and MAY use - -00:00 for backwards compatibility."; - reference - "RFC 3339: Date and Time on the Internet: Timestamps - RFC 9557: Date and Time on the Internet: Timestamps - with Additional Information - RFC 2579: Textual Conventions for SMIv2 - XSD-TYPES: XML Schema Definition Language (XSD) 1.1 - Part 2: Datatypes"; - } - - typedef date { - type string { - pattern - '[0-9]{4}-(1[0-2]|0[1-9])-(0[1-9]|[1-2][0-9]|3[0-1])' - + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; - } - description - "The date type represents a time-interval of the length - of a day, i.e., 24 hours. It includes an optional time - zone offset. - - The date type is compatible with the XML schema date - type with the following notable exceptions: - - (a) The date type does not allow negative years. - - (b) The time-offset Z indicates that the date value is - reported in UTC and that the local time zone reference - point is unknown. The time-offset +00:00 indicates that - the date value is reported in UTC and that the local - time reference point is UTC (see RFC 9557 section 2). - - The canonical format for date values with a known time - 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 offset to UTC time will cause date values - to change accordingly. Such changes might happen periodically - in case a server follows automatically daylight saving time - (DST) time zone offset changes. The canonical format for - date values reported in UTC with an unknown local time zone - offset uses the time-offset Z."; - reference - "RFC 3339: Date and Time on the Internet: Timestamps - RFC 9557: Date and Time on the Internet: Timestamps - with Additional Information - XSD-TYPES: XML Schema Definition Language (XSD) 1.1 - Part 2: Datatypes"; - } - - typedef date-no-zone { - type date { - pattern '[0-9]{4}-(1[0-2]|0[1-9])-(0[1-9]|[1-2][0-9]|3[0-1])'; - } - description - "The date-no-zone type represents a date without the optional - time zone offset information."; - } - - typedef time { - type string { - pattern - '(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))?'; - } - description - "The time type represents an instance of time of zero-duration - that recurs every day. It includes an optional time zone - offset. The value of 60 for seconds is allowed only in the - case of leap seconds. - - The time type is compatible with the XML schema time - type with the following notable exception: - - (a) The time-offset Z indicates that the time value is - reported in UTC and that the local time zone reference - point is unknown. The time-offset +00:00 indicates that - the time value is reported in UTC and that the local - time reference point is UTC (see RFC 9557 section 2). - - The canonical format for time values with a known time - 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 offset to UTC time will cause time values - to change accordingly. Such changes might happen periodically - in case a server follows automatically daylight saving time - (DST) time zone offset changes. The canonical format for - time values reported in UTC with an unknown local time zone - offset uses the time-offset Z."; - reference - "RFC 3339: Date and Time on the Internet: Timestamps - RFC 9557: Date and Time on the Internet: Timestamps - with Additional Information - XSD-TYPES: XML Schema Definition Language (XSD) 1.1 - Part 2: Datatypes"; - } - - typedef time-no-zone { - type time { - pattern - '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:([0-5][0-9]|60)(\.[0-9]+)?'; - } - description - "The time-no-zone type represents a time without the optional - time zone offset information."; - } - - typedef hours32 { - type int32; - units "hours"; - description - "A period of time, measured in units of hours. - - The maximum time period that can be expressed is in the - range [-89478485 days 08:00:00 to 89478485 days 07:00:00]. - - This type should be range restricted in situations - where only non-negative time periods are desirable, - (i.e., range '0..max')."; - } - - typedef minutes32 { - type int32; - units "minutes"; - description - "A period of time, measured in units of minutes. - - The maximum time period that can be expressed is in the - range [-1491308 days 2:08:00 to 1491308 days 2:07:00]. - - This type should be range restricted in situations - where only non-negative time periods are desirable, - (i.e., range '0..max')."; - } - - typedef seconds32 { - type int32; - units "seconds"; - description - "A period of time, measured in units of seconds. - - The maximum time period that can be expressed is in the - range [-24855 days 03:14:08 to 24855 days 03:14:07]. - - This type should be range restricted in situations - where only non-negative time periods are desirable, - (i.e., range '0..max')."; - } - - typedef centiseconds32 { - type int32; - units "centiseconds"; - description - "A period of time, measured in units of 10^-2 seconds. - - The maximum time period that can be expressed is in the - range [-248 days 13:13:56 to 248 days 13:13:56]. - - This type should be range restricted in situations - where only non-negative time periods are desirable, - (i.e., range '0..max')."; - } - - typedef milliseconds32 { - type int32; - units "milliseconds"; - description - "A period of time, measured in units of 10^-3 seconds. - - The maximum time period that can be expressed is in the - range [-24 days 20:31:23 to 24 days 20:31:23]. - - This type should be range restricted in situations - where only non-negative time periods are desirable, - (i.e., range '0..max')."; - } - - typedef microseconds32 { - type int32; - units "microseconds"; - description - "A period of time, measured in units of 10^-6 seconds. - - The maximum time period that can be expressed is in the - range [-00:35:47 to 00:35:47]. - - This type should be range restricted in situations - where only non-negative time periods are desirable, - (i.e., range '0..max')."; - } - - typedef microseconds64 { - type int64; - units "microseconds"; - description - "A period of time, measured in units of 10^-6 seconds. - - The maximum time period that can be expressed is in the - range [-106751991 days 04:00:54 to 106751991 days 04:00:54]. - - This type should be range restricted in situations - where only non-negative time periods are desirable, - (i.e., range '0..max')."; - } - - typedef nanoseconds32 { - type int32; - units "nanoseconds"; - description - "A period of time, measured in units of 10^-9 seconds. - - The maximum time period that can be expressed is in the - range [-00:00:02 to 00:00:02]. - - This type should be range restricted in situations - where only non-negative time periods are desirable, - (i.e., range '0..max')."; - } - - typedef nanoseconds64 { - type int64; - units "nanoseconds"; - description - "A period of time, measured in units of 10^-9 seconds. - - The maximum time period that can be expressed is in the - range [-106753 days 23:12:44 to 106752 days 0:47:16]. - - This type should be range restricted in situations - where only non-negative time periods are desirable, - (i.e., range '0..max')."; - } - - typedef timeticks { - type uint32; - description - "The timeticks type represents a non-negative integer that - represents the time, modulo 2^32 (4294967296 decimal), in - hundredths of a second between two epochs. When a schema - node is defined that uses this type, the description of - the schema node identifies both of the reference epochs. - - In the value set and its semantics, this type is equivalent - to the TimeTicks type of the SMIv2."; - reference - "RFC 2578: Structure of Management Information Version 2 - (SMIv2)"; - } - - typedef timestamp { - type timeticks; - description - "The timestamp type represents the value of an associated - timeticks schema node instance at which a specific occurrence - happened. The specific occurrence must be defined in the - description of any schema node defined using this type. When - the specific occurrence occurred prior to the last time the - associated timeticks schema node instance was zero, then the - timestamp value is zero. - - Note that this requires all timestamp values to be reset to - zero when the value of the associated timeticks schema node - instance reaches 497+ days and wraps around to zero. - - The associated timeticks schema node must be specified - in the description of any schema node using this type. - - In the value set and its semantics, this type is equivalent - to the TimeStamp textual convention of the SMIv2."; - reference - "RFC 2579: Textual Conventions for SMIv2"; - } - - /*** collection of generic address types ***/ - - typedef phys-address { - type string { - pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?'; - } - description - "Represents media- or physical-level addresses represented - as a sequence octets, each octet represented by two hexadecimal - numbers. Octets are separated by colons. The canonical - representation uses lowercase characters. - - In the value set and its semantics, this type is equivalent - to the PhysAddress textual convention of the SMIv2."; - reference - "RFC 2579: Textual Conventions for SMIv2"; - } - - typedef mac-address { - type string { - pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}'; - } - description - "The mac-address type represents a 48-bit IEEE 802 MAC - address. The canonical representation uses lowercase - characters. Note that there are IEEE 802 MAC addresses - with a different length that this type cannot represent. - The phys-address type may be used to represent physical - addresses of varying length. - - In the value set and its semantics, this type is equivalent - to the MacAddress textual convention of the SMIv2."; - reference - "IEEE 802: IEEE Standard for Local and Metropolitan Area - Networks: Overview and Architecture - RFC 2579: Textual Conventions for SMIv2"; - } - - /*** collection of XML-specific types ***/ - - typedef xpath1.0 { - type string; - description - "This type represents an XPATH 1.0 expression. - - When a schema node is defined that uses this type, the - description of the schema node MUST specify the XPath - context in which the XPath expression is evaluated."; - reference - "XPATH: XML Path Language (XPath) Version 1.0"; - } - - /*** collection of string types ***/ - - typedef hex-string { - type string { - pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?'; - } - description - "A hexadecimal string with octets represented as hex digits - separated by colons. The canonical representation uses - lowercase characters."; - } - - typedef uuid { - type string { - 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}'; - } - description - "A Universally Unique IDentifier in the string representation - defined in RFC 4122. The canonical representation uses - lowercase characters. - - The following is an example of a UUID in string representation: - f81d4fae-7dec-11d0-a765-00a0c91e6bf6 - "; - reference - "RFC 4122: A Universally Unique IDentifier (UUID) URN - Namespace"; - } - - typedef dotted-quad { - type string { - 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])'; - } - description - "An unsigned 32-bit number expressed in the dotted-quad - notation, i.e., four octets written as decimal numbers - and separated with the '.' (full stop) character."; - } - - typedef language-tag { - type string; - description - "A language tag according to RFC 5646 (BCP 47). The - canonical representation uses lowercase characters. - - Values of this type must be well-formed language tags, - in conformance with the definition of well-formed tags - in BCP 47. Implementations MAY further limit the values - they accept to those permitted by a 'validating' - processor, as defined in BCP 47. - - The canonical representation of values of this type is - aligned with the SMIv2 LangTag textual convention for - language tags fitting the length constraints imposed - by the LangTag textual convention."; - reference - "RFC 5646: Tags for Identifying Languages - RFC 5131: A MIB Textual Convention for Language Tags"; - } - - /*** collection of YANG specific types ***/ - - typedef yang-identifier { - type string { - length "1..max"; - pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*'; - } - description - "A YANG identifier string as defined by the 'identifier' - rule in Section 14 of RFC 7950. An identifier must - start with an alphabetic character or an underscore - followed by an arbitrary sequence of alphabetic or - numeric characters, underscores, hyphens, or dots. - - This definition conforms to YANG 1.1 defined in RFC - 7950. An earlier version of this definition excluded - all identifiers starting with any possible combination - of the lowercase or uppercase character sequence 'xml', - as required by YANG 1 defined in RFC 6020. If this type - is used in a YANG 1 context, then this restriction still - applies."; - reference - "RFC 7950: The YANG 1.1 Data Modeling Language - RFC 6020: YANG - A Data Modeling Language for the - Network Configuration Protocol (NETCONF)"; - } - -} diff --git a/standard/ietf/RFC/ietf-inet-types.yang b/standard/ietf/RFC/ietf-inet-types.yang index f2c4cfeed..f476dba7d 120000 --- a/standard/ietf/RFC/ietf-inet-types.yang +++ b/standard/ietf/RFC/ietf-inet-types.yang @@ -1 +1 @@ -ietf-inet-types@2013-07-15.yang \ No newline at end of file +ietf-inet-types@2025-12-22.yang \ No newline at end of file diff --git a/standard/ietf/RFC/ietf-inet-types@2025-12-22.yang b/standard/ietf/RFC/ietf-inet-types@2025-12-22.yang new file mode 100644 index 000000000..38c4971b8 --- /dev/null +++ b/standard/ietf/RFC/ietf-inet-types@2025-12-22.yang @@ -0,0 +1,666 @@ +module ietf-inet-types { + namespace "urn:ietf:params:xml:ns:yang:ietf-inet-types"; + prefix inet; + + organization + "IETF Network Modeling (NETMOD) Working Group"; + contact + "WG Web: + WG List: + + Editor: Jürgen Schönwälder + "; + description + "This module contains a collection of generally useful derived + YANG data types for Internet addresses and related things. + + The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL + NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', + 'MAY', and 'OPTIONAL' in this document are to be interpreted as + described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, + they appear in all capitals, as shown here. + + Copyright (c) 2025 IETF Trust and the persons identified as + authors of the code. All rights reserved. + + Redistribution and use in source and binary forms, with or + without modification, is permitted pursuant to, and subject + to the license terms contained in, the Revised BSD License + set forth in Section 4.c of the IETF Trust's Legal Provisions + Relating to IETF Documents + (https://trustee.ietf.org/license-info). + + This version of this YANG module is part of RFC 9911; + see the RFC itself for full legal notices."; + + revision 2025-12-22 { + description + "This revision adds the following new data types: + - inet:ip-address-and-prefix + - inet:ipv4-address-and-prefix + - inet:ipv6-address-and-prefix + - inet:protocol-number + - inet:upper-layer-protocol-number + - inet:host-name + - inet:email-address + - inet:ip-address-link-local + - inet:ipv4-address-link-local + - inet:ipv6-address-link-local + The inet:host union was changed to use inet:host-name instead + of inet:domain-name. Several pattern statements have been + improved."; + reference + "RFC 9911: Common YANG Data Types"; + } + revision 2013-07-15 { + description + "This revision adds the following new data types: + - inet:ip-address-no-zone + - inet:ipv4-address-no-zone + - inet:ipv6-address-no-zone"; + reference + "RFC 6991: Common YANG Data Types"; + } + revision 2010-09-24 { + description + "Initial revision."; + reference + "RFC 6021: Common YANG Data Types"; + } + + /*** collection of types related to protocol fields ***/ + + typedef ip-version { + type enumeration { + enum unknown { + value 0; + description + "An unknown or unspecified version of the Internet + Protocol."; + } + enum ipv4 { + value 1; + description + "The IPv4 protocol as defined in RFC 791."; + } + enum ipv6 { + value 2; + description + "The IPv6 protocol as defined in RFC 8200."; + } + } + description + "This value represents the version of the Internet Protocol. + + In the value set and its semantics, this type is equivalent + to the InetVersion textual convention of the SMIv2."; + reference + "RFC 791: Internet Protocol + RFC 8200: Internet Protocol, Version 6 (IPv6) Specification + RFC 4001: Textual Conventions for Internet Network Addresses"; + } + + typedef dscp { + type uint8 { + range "0..63"; + } + description + "The dscp type represents a Differentiated Services Code Point + that may be used for marking packets in a traffic stream. + + In the value set and its semantics, this type is equivalent + to the Dscp textual convention of the SMIv2."; + reference + "RFC 3289: Management Information Base for the Differentiated + Services Architecture + RFC 2474: Definition of the Differentiated Services Field + (DS Field) in the IPv4 and IPv6 Headers + RFC 2780: IANA Allocation Guidelines For Values In + the Internet Protocol and Related Headers"; + } + + typedef ipv6-flow-label { + type uint32 { + range "0..1048575"; + } + description + "The ipv6-flow-label type represents the flow identifier or + Flow Label in an IPv6 packet header that may be used to + discriminate traffic flows. + + In the value set and its semantics, this type is equivalent + to the IPv6FlowLabel textual convention of the SMIv2."; + reference + "RFC 3595: Textual Conventions for IPv6 Flow Label + RFC 8200: Internet Protocol, Version 6 (IPv6) Specification"; + } + + typedef port-number { + type uint16 { + range "0..65535"; + } + description + "The port-number type represents a 16-bit port number of an + Internet transport-layer protocol such as UDP, TCP, DCCP, or + SCTP. + + Port numbers are assigned by IANA. The current list of + all assignments is available from . + + Note that the port number value zero is reserved by IANA. In + situations where the value zero does not make sense, it can + be excluded by subtyping the port-number type. + + In the value set and its semantics, this type is equivalent + to the InetPortNumber textual convention of the SMIv2."; + reference + "RFC 768: User Datagram Protocol + RFC 9293: Transmission Control Protocol (TCP) + RFC 9260: Stream Control Transmission Protocol + RFC 4340: Datagram Congestion Control Protocol (DCCP) + RFC 4001: Textual Conventions for Internet Network Addresses"; + } + + typedef protocol-number { + type uint8; + description + "The protocol-number type represents an 8-bit Internet + Protocol number, carried in the 'protocol' field of the + IPv4 header or in the 'next header' field of the IPv6 + header. + + Protocol numbers are assigned by IANA. The current list of + all assignments is available from ."; + reference + "RFC 791: Internet Protocol + RFC 8200: Internet Protocol, Version 6 (IPv6) Specification"; + } + + typedef upper-layer-protocol-number { + type protocol-number; + description + "The upper-layer-protocol-number represents the upper-layer + protocol number carried in an IP packet. For IPv6 packets + with extension headers, this is the protocol number carried + in the last 'next header' field of the chain of IPv6 extension + headers."; + reference + "RFC 791: Internet Protocol + RFC 8200: Internet Protocol, Version 6 (IPv6) Specification"; + } + + /*** collection of types related to autonomous systems ***/ + + typedef as-number { + type uint32; + description + "The as-number type represents autonomous system numbers + that identify an Autonomous System (AS). An AS is a set + of routers under a single technical administration, using + an interior gateway protocol and common metrics to route + packets within the AS, and using an exterior gateway + protocol to route packets to other ASes. IANA maintains + the autonomous system number space and has delegated large + parts to the regional registries. + + Autonomous system numbers were originally limited to 16 + bits. BGP extensions have enlarged the autonomous system + number space to 32 bits. This type therefore uses an uint32 + base type without a range restriction in order to support + a larger autonomous system number space. + + In the value set and its semantics, this type is equivalent + to the InetAutonomousSystemNumber textual convention of + the SMIv2."; + reference + "RFC 1930: Guidelines for creation, selection, and registration + of an Autonomous System (AS) + RFC 4271: A Border Gateway Protocol 4 (BGP-4) + RFC 4001: Textual Conventions for Internet Network Addresses + RFC 6793: BGP Support for Four-Octet Autonomous System (AS) + Number Space"; + } + + /*** collection of types related to IP addresses and hostnames ***/ + + typedef ip-address { + type union { + type ipv4-address; + type ipv6-address; + } + description + "The ip-address type represents an IP address and is IP + version neutral. The format of the textual representation + implies the IP version. This type supports scoped addresses + by allowing zone identifiers in the address format."; + reference + "RFC 4007: IPv6 Scoped Address Architecture"; + } + + typedef ipv4-address { + type string { + 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])' + + '(%.+)?'; + } + description + "The ipv4-address type represents an IPv4 address in + dotted-quad notation. The IPv4 address may include a zone + index, separated by a % sign. If a system uses zone names + that are not represented in UTF-8, then an implementation + needs to use some mechanism to transform the local name + into UTF-8. The definition of such a mechanism is outside + the scope of this document. + + The zone index is used to disambiguate identical address + values. For link-local addresses, the zone index will + typically be the interface index number or the name of an + interface. If the zone index is not present, the default + zone of the device will be used. + + The canonical format for the zone index is the numerical + format"; + } + + typedef ipv6-address { + type string { + pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' + + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' + + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' + + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' + + '(%[A-Za-z0-9][A-Za-z0-9\-\._~/]*)?'; + pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' + + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' + + '(%.+)?'; + } + description + "The ipv6-address type represents an IPv6 address in full, + mixed, shortened, and shortened-mixed notation. The IPv6 + address may include a zone index, separated by a % sign. + If a system uses zone names that are not represented in + UTF-8, then an implementation needs to use some mechanism + to transform the local name into UTF-8. The definition of + such a mechanism is outside the scope of this document. + + The zone index is used to disambiguate identical address + values. For link-local addresses, the zone index will + typically be the interface index number or the name of an + interface. If the zone index is not present, the default + zone of the device will be used. + + The canonical format of IPv6 addresses uses the textual + representation defined in Section 4 of RFC 5952. The + canonical format for the zone index is the numerical + format as described in Section 11.2 of RFC 4007."; + reference + "RFC 4291: IP Version 6 Addressing Architecture + RFC 4007: IPv6 Scoped Address Architecture + RFC 5952: A Recommendation for IPv6 Address Text + Representation"; + } + + typedef ip-address-no-zone { + type union { + type ipv4-address-no-zone; + type ipv6-address-no-zone; + } + description + "The ip-address-no-zone type represents an IP address and is + IP version neutral. The format of the textual representation + implies the IP version. This type does not support scoped + addresses since it does not allow zone identifiers in the + address format."; + reference + "RFC 4007: IPv6 Scoped Address Architecture"; + } + + typedef ipv4-address-no-zone { + type ipv4-address { + pattern '[0-9\.]*'; + } + description + "An IPv4 address without a zone index. This type, derived + from the type ipv4-address, may be used in situations where + the zone is known from the context and no zone index is + needed."; + } + + typedef ipv6-address-no-zone { + type ipv6-address { + pattern '[0-9a-fA-F:\.]*'; + } + description + "An IPv6 address without a zone index. This type, derived + from the type ipv6-address, may be used in situations where + the zone is known from the context and no zone index is + needed."; + reference + "RFC 4291: IP Version 6 Addressing Architecture + RFC 4007: IPv6 Scoped Address Architecture + RFC 5952: A Recommendation for IPv6 Address Text + Representation"; + } + + typedef ip-address-link-local { + type union { + type ipv4-address-link-local; + type ipv6-address-link-local; + } + description + "The ip-address-link-local type represents a link-local IP + address and is IP version neutral. The format of the textual + representation implies the IP version."; + } + + typedef ipv4-address-link-local { + type ipv4-address { + pattern '169\.254\..*'; + } + description + "The ipv4-address-link-local type represents a link-local IPv4 + address in the prefix 169.254.0.0/16 as defined in Section 2.1 + of RFC 3927."; + reference + "RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses"; + } + + typedef ipv6-address-link-local { + type ipv6-address { + pattern '[fF][eE][89aAbB][0-9a-fA-F]:.*'; + } + description + "The ipv6-address-link-local type represents a link-local IPv6 + address in the prefix fe80::/10 as defined in Section 2.4 of + RFC 4291."; + reference + "RFC 4291: IP Version 6 Addressing Architecture"; + } + + typedef ip-prefix { + type union { + type ipv4-prefix; + type ipv6-prefix; + } + description + "The ip-prefix type represents an IP prefix and is IP + version neutral. The format of the textual representations + implies the IP version."; + } + + typedef ipv4-prefix { + type string { + 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])' + + '/(([0-9])|([1-2][0-9])|(3[0-2]))'; + } + description + "The ipv4-prefix type represents an IPv4 prefix. + The prefix length is given by the number following the + slash character and must be less than or equal to 32. + + A prefix length value of n corresponds to an IP address + mask that has n contiguous 1-bits from the most + significant bit (MSB) and all other bits set to 0. + + The canonical format of an IPv4 prefix has all bits of + the IPv4 address set to zero that are not part of the + IPv4 prefix. + + The definition of ipv4-prefix does not require that bits + that are not part of the prefix be set to zero. However, + implementations have to return values in canonical format, + which requires non-prefix bits to be set to zero. This means + that 192.0.2.1/24 must be accepted as a valid value, but it + will be converted into the canonical format 192.0.2.0/24."; + } + + typedef ipv6-prefix { + type string { + pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' + + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' + + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' + + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' + + '(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))'; + pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' + + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' + + '(/.+)'; + } + description + "The ipv6-prefix type represents an IPv6 prefix. + The prefix length is given by the number following the + slash character and must be less than or equal to 128. + + A prefix length value of n corresponds to an IP address + mask that has n contiguous 1-bits from the most + significant bit (MSB) and all other bits set to 0. + + The canonical format of an IPv6 prefix has all bits of + the IPv6 address set to zero that are not part of the + IPv6 prefix. Furthermore, the IPv6 address is represented + as defined in Section 4 of RFC 5952. + + The definition of ipv6-prefix does not require that bits + that are not part of the prefix be set to zero. However, + implementations have to return values in canonical format, + which requires non-prefix bits to be set to zero. This means + that 2001:db8::1/64 must be accepted as a valid value, but it + will be converted into the canonical format 2001:db8::/64."; + reference + "RFC 5952: A Recommendation for IPv6 Address Text + Representation"; + } + + typedef ip-address-and-prefix { + type union { + type ipv4-address-and-prefix; + type ipv6-address-and-prefix; + } + description + "The ip-address-and-prefix type represents an IP address and + prefix and is IP version neutral. The format of the textual + representations implies the IP version."; + } + + typedef ipv4-address-and-prefix { + type string { + 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])' + + '/(([0-9])|([1-2][0-9])|(3[0-2]))'; + } + description + "The ipv4-address-and-prefix type represents an IPv4 + address and an associated IPv4 prefix. + The prefix length is given by the number following the + slash character and must be less than or equal to 32. + + A prefix length value of n corresponds to an IP address + mask that has n contiguous 1-bits from the most + significant bit (MSB) and all other bits set to 0."; + } + + typedef ipv6-address-and-prefix { + type string { + pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' + + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' + + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' + + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' + + '(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))'; + pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' + + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' + + '(/.+)'; + } + description + "The ipv6-address-and-prefix type represents an IPv6 + address and an associated IPv6 prefix. + The prefix length is given by the number following the + slash character and must be less than or equal to 128. + + A prefix length value of n corresponds to an IP address + mask that has n contiguous 1-bits from the most + significant bit (MSB) and all other bits set to 0. + + The canonical format requires that the IPv6 address is + represented as defined in Section 4 of RFC 5952."; + reference + "RFC 5952: A Recommendation for IPv6 Address Text + Representation"; + } + + /*** collection of domain name and URI types ***/ + + typedef domain-name { + type string { + length "1..253"; + 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]\.?)' + + '|\.'; + } + description + "The domain-name type represents a DNS domain name. The + name SHOULD be fully qualified whenever possible. This + type does not support wildcards (see RFC 4592) or + classless in-addr.arpa delegations (see RFC 2317). + + Internet domain names are only loosely specified. Section + 3.5 of RFC 1034 recommends a syntax (modified in Section + 2.1 of RFC 1123). The pattern above is intended to allow + for current practice in domain name use and some possible + future expansion. Note that Internet host names have a + stricter syntax (described in RFC 952) than the DNS + recommendations in RFCs 1034 and 1123. Schema nodes + representing host names should use the host-name type + instead of the domain-type. + + The encoding of DNS names in the DNS protocol is limited + to 255 characters. Since the encoding consists of labels + prefixed by a length byte and there is a trailing NUL + byte, only 253 characters can appear in the textual dotted + notation. + + The description clause of schema nodes using the domain-name + type MUST describe when and how these names are resolved to + IP addresses. Note that the resolution of a domain-name value + may require to query multiple DNS records (e.g., A for IPv4 + and AAAA for IPv6). The order of the resolution process and + which DNS record takes precedence can either be defined + explicitly or depend on the configuration of the + resolver. + + Domain-name values use the ASCII encoding. Their canonical + format uses lowercase ASCII characters. Internationalized + domain names MUST be A-labels as per RFC 5890."; + reference + "RFC 952: DoD Internet Host Table Specification + RFC 1034: Domain Names - Concepts and Facilities + RFC 1123: Requirements for Internet Hosts -- Application + and Support + RFC 2317: Classless IN-ADDR.ARPA delegation + RFC 2782: A DNS RR for specifying the location of services + (DNS SRV) + RFC 4592: The Role of Wildcards in the Domain Name System + RFC 5890: Internationalized Domain Names in Applications + (IDNA): Definitions and Document Framework + RFC 9499: DNS Terminology"; + } + + typedef host-name { + type domain-name { + length "2..max"; + pattern '[a-zA-Z0-9\-\.]+'; + } + description + "The host-name type represents fully qualified host names. + Host names must be at least two characters long (see RFC 952), + and they are restricted to labels consisting of letters, + digits, and hyphens separated by dots (see RFCs 1123 and + 952)."; + reference + "RFC 952: DoD Internet Host Table Specification + RFC 1123: Requirements for Internet Hosts -- Application + and Support"; + } + + typedef host { + type union { + type ip-address; + type host-name; + } + description + "The host type represents either an IP address or a fully + qualified host name."; + } + + typedef uri { + type string { + pattern '[a-z][a-z0-9+.-]*:.*'; + } + description + "The uri type represents a Uniform Resource Identifier + (URI) as defined by the rule 'URI' in RFC 3986. + + Objects using the uri type MUST be in ASCII encoding + 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 + represented without using percent-encoding are represented + as characters (without percent-encoding), and all + case-insensitive characters are set to lowercase except + for hexadecimal digits within a percent-encoded triplet, + which are normalized to uppercase as described in + Section 6.2.2.1 of RFC 3986. + + The purpose of this normalization is to help provide + unique URIs. Note that this normalization is not + sufficient to provide uniqueness. Two URIs that are + textually distinct after this normalization may still be + equivalent. + + Objects using the uri type may restrict the schemes that + they permit. For example, 'data:' and 'urn:' schemes + might not be appropriate. + + A zero-length URI is not a valid URI. This can be used to + express 'URI absent' where required. + + In the value set and its semantics, this type is equivalent + to the Uri SMIv2 textual convention defined in RFC 5017."; + reference + "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax + RFC 3305: Report from the Joint W3C/IETF URI Planning Interest + Group: Uniform Resource Identifiers (URIs), URLs, + and Uniform Resource Names (URNs): Clarifications + and Recommendations + RFC 5017: MIB Textual Conventions for Uniform Resource + Identifiers (URIs)"; + } + + typedef email-address { + type string { + pattern '.+@.+'; + } + description + "The email-address type represents an internationalized + email address. + + The email address format is defined by the addr-spec + ABNF rule in Section 3.4.1 of RFC 5322. This format has + been extended by RFC 6532 to support internationalized + email addresses. Implementations MUST support the + internationalization extensions of RFC 6532. Support + for the obsolete obs-local-part, obs-domain, and + obs-qtext in RFC 5322 is not required. + + The domain part may use both A-labels and U-labels + (see RFC 5890). The canonical format of the domain part + uses lowercase characters and U-labels (RFC 5890) where + applicable."; + reference + "RFC 5322: Internet Message Format + RFC 5890: Internationalized Domain Names in Applications + (IDNA): Definitions and Document Framework + RFC 6532: Internationalized Email Headers"; + } +} diff --git a/standard/ietf/RFC/ietf-yang-types.yang b/standard/ietf/RFC/ietf-yang-types.yang index a9d02a25f..00a90d0d3 120000 --- a/standard/ietf/RFC/ietf-yang-types.yang +++ b/standard/ietf/RFC/ietf-yang-types.yang @@ -1 +1 @@ -ietf-yang-types@2013-07-15.yang \ No newline at end of file +ietf-yang-types@2025-12-22.yang \ No newline at end of file diff --git a/standard/ietf/RFC/ietf-yang-types@2025-12-22.yang b/standard/ietf/RFC/ietf-yang-types@2025-12-22.yang new file mode 100644 index 000000000..0ba3b341e --- /dev/null +++ b/standard/ietf/RFC/ietf-yang-types@2025-12-22.yang @@ -0,0 +1,764 @@ +module ietf-yang-types { + namespace "urn:ietf:params:xml:ns:yang:ietf-yang-types"; + prefix yang; + + organization + "IETF Network Modeling (NETMOD) Working Group"; + contact + "WG Web: + WG List: + + Editor: Jürgen Schönwälder + "; + description + "This module contains a collection of generally useful derived + YANG data types. + + The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL + NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', + 'MAY', and 'OPTIONAL' in this document are to be interpreted as + described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, + they appear in all capitals, as shown here. + + Copyright (c) 2025 IETF Trust and the persons identified as + authors of the code. All rights reserved. + + Redistribution and use in source and binary forms, with or + without modification, is permitted pursuant to, and subject + to the license terms contained in, the Revised BSD License + set forth in Section 4.c of the IETF Trust's Legal Provisions + Relating to IETF Documents + (https://trustee.ietf.org/license-info). + + This version of this YANG module is part of RFC 9911; + see the RFC itself for full legal notices."; + + revision 2025-12-22 { + description + "This revision adds the following new data types: + - yang:date + - yang:date-no-zone + - yang:time + - yang:time-no-zone + - yang:hours32 + - yang:minutes32 + - yang:seconds32 + - yang:centiseconds32 + - yang:milliseconds32 + - yang:microseconds32 + - yang:microseconds64 + - yang:nanoseconds32 + - yang:nanoseconds64 + - yang:language-tag + The yang-identifier definition has been aligned with YANG + 1.1, and types representing time support the representation + of leap seconds. The representation of time zone offsets + has been aligned with RFC 9557. Several description and + pattern statements have been improved."; + reference + "RFC 9911: Common YANG Data Types"; + } + revision 2013-07-15 { + description + "This revision adds the following new data types: + - yang:yang-identifier + - yang:hex-string + - yang:uuid + - yang:dotted-quad"; + reference + "RFC 6991: Common YANG Data Types"; + } + revision 2010-09-24 { + description + "Initial revision."; + reference + "RFC 6021: Common YANG Data Types"; + } + + /*** collection of counter and gauge types ***/ + + typedef counter32 { + type uint32; + description + "The counter32 type represents a non-negative integer + that monotonically increases until it reaches a + maximum value of 2^32-1 (4294967295 decimal), when it + wraps around and starts increasing again from zero. + + Counters have no defined 'initial' value, and thus, a + single value of a counter has (in general) no information + content. Discontinuities in the monotonically increasing + value normally occur at re-initialization of the + management system and at other times as specified in the + description of a schema node using this type. If + discontinuities occur at times other than re-initialization + (for example, at the instantiation of a schema node of type + counter32), then a corresponding schema node should be + defined, with an appropriate type, to indicate the last + discontinuity. + + The counter32 type should not be used for configuration + schema nodes. A default statement SHOULD NOT be used in + combination with the type counter32. + + In the value set and its semantics, this type is equivalent + to the Counter32 type of the SMIv2."; + reference + "RFC 2578: Structure of Management Information Version 2 + (SMIv2)"; + } + + typedef zero-based-counter32 { + type counter32; + default "0"; + description + "The zero-based-counter32 type represents a counter32 + that has the defined 'initial' value zero. + + A data tree node using this type will be set to zero (0) + on creation and will thereafter increase monotonically until + it reaches a maximum value of 2^32-1 (4294967295 decimal), + when it wraps around and starts increasing again from zero. + + Provided that an application discovers a new data tree node + using this type within the minimum time to wrap, it can use + the 'initial' value as a delta. It is important for a + management station to be aware of this minimum time and the + actual time between polls, and to discard data if the actual + time is too long or there is no defined minimum time. + + In the value set and its semantics, this type is equivalent + to the ZeroBasedCounter32 textual convention of the SMIv2."; + reference + "RFC 4502: Remote Network Monitoring Management Information + Base Version 2"; + } + + typedef counter64 { + type uint64; + description + "The counter64 type represents a non-negative integer + that monotonically increases until it reaches a + maximum value of 2^64-1 (18446744073709551615 decimal), + when it wraps around and starts increasing again from zero. + + Counters have no defined 'initial' value, and thus, a + single value of a counter has (in general) no information + content. Discontinuities in the monotonically increasing + value normally occur at re-initialization of the + management system and at other times as specified in the + description of a schema node using this type. If + discontinuities occur at times other than re-initialization + (for example, at the instantiation of a schema node of type + counter64), then a corresponding schema node should be + defined, with an appropriate type, to indicate the last + discontinuity. + + The counter64 type should not be used for configuration + schema nodes. A default statement SHOULD NOT be used in + combination with the type counter64. + + In the value set and its semantics, this type is equivalent + to the Counter64 type of the SMIv2."; + reference + "RFC 2578: Structure of Management Information Version 2 + (SMIv2)"; + } + + typedef zero-based-counter64 { + type counter64; + default "0"; + description + "The zero-based-counter64 type represents a counter64 that + has the defined 'initial' value zero. + + A data tree node using this type will be set to zero (0) + on creation and will thereafter increase monotonically until + it reaches a maximum value of 2^64-1 (18446744073709551615 + decimal), when it wraps around and starts increasing again + from zero. + + Provided that an application discovers a new data tree node + using this type within the minimum time to wrap, it can use + the 'initial' value as a delta. It is important for a + management station to be aware of this minimum time and the + actual time between polls, and to discard data if the actual + time is too long or there is no defined minimum time. + + In the value set and its semantics, this type is equivalent + to the ZeroBasedCounter64 textual convention of the SMIv2."; + reference + "RFC 2856: Textual Conventions for Additional High Capacity + Data Types"; + } + + typedef gauge32 { + type uint32; + description + "The gauge32 type represents a non-negative integer, which + may increase or decrease, but shall never exceed a maximum + value, nor fall below a minimum value. The maximum value + cannot be greater than 2^32-1 (4294967295 decimal), and + the minimum value cannot be smaller than 0. The value of + a gauge32 has its maximum value whenever the information + being modeled is greater than or equal to its maximum + value, and has its minimum value whenever the information + being modeled is smaller than or equal to its minimum value. + If the information being modeled subsequently decreases below + the maximum value, the gauge32 also decreases; likewise, if + the information increases above the minimum value, the + gauge32 also increases. + + In the value set and its semantics, this type is equivalent + to the Gauge32 type of the SMIv2."; + reference + "RFC 2578: Structure of Management Information Version 2 + (SMIv2)"; + } + + typedef gauge64 { + type uint64; + description + "The gauge64 type represents a non-negative integer, which + may increase or decrease, but shall never exceed a maximum + value, nor fall below a minimum value. The maximum value + cannot be greater than 2^64-1 (18446744073709551615), and + the minimum value cannot be smaller than 0. The value of + a gauge64 has its maximum value whenever the information + being modeled is greater than or equal to its maximum + value, and has its minimum value whenever the information + being modeled is smaller than or equal to its minimum value. + If the information being modeled subsequently decreases + below (increases above) the maximum (minimum) value, the + gauge64 also decreases (increases). + + In the value set and its semantics, this type is equivalent + to the CounterBasedGauge64 SMIv2 textual convention defined + in RFC 2856"; + reference + "RFC 2856: Textual Conventions for Additional High Capacity + Data Types"; + } + + /*** collection of identifier-related types ***/ + + typedef object-identifier { + type string { + pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9][0-9]*))))' + + '(\.(0|([1-9][0-9]*)))*'; + } + description + "The object-identifier type represents administratively + assigned names in a registration-hierarchical-name tree. + + Values of this type are denoted as a sequence of numerical + non-negative sub-identifier values. Each sub-identifier + value MUST NOT exceed 2^32-1 (4294967295). Sub-identifiers + are separated by single dots and without any intermediate + whitespace. + + The ASN.1 standard restricts the value space of the first + sub-identifier to 0, 1, or 2. Furthermore, the value space + of the second sub-identifier is restricted to the range + 0 to 39 if the first sub-identifier is 0 or 1. Finally, + the ASN.1 standard requires that an object identifier + has always at least two sub-identifiers. The pattern + captures these restrictions. + + Although the number of sub-identifiers is not limited, + module designers should realize that there may be + implementations that stick with the SMIv2 limit of 128 + sub-identifiers. + + This type is a superset of the SMIv2 OBJECT IDENTIFIER type + since it is not restricted to 128 sub-identifiers. Hence, + this type SHOULD NOT be used to represent the SMIv2 OBJECT + IDENTIFIER type; the object-identifier-128 type SHOULD be + used instead."; + reference + "ISO 9834-1: Information technology -- Procedures for the + operation of object identifier registration authorities -- + Part 1: General procedures and top arcs of the international + object identifier tree"; + } + + typedef object-identifier-128 { + type object-identifier { + pattern '[0-9]*(\.[0-9]*){1,127}'; + } + description + "This type represents object-identifiers restricted to 128 + sub-identifiers. + + In the value set and its semantics, this type is equivalent + to the OBJECT IDENTIFIER type of the SMIv2."; + reference + "RFC 2578: Structure of Management Information Version 2 + (SMIv2)"; + } + + /*** collection of types related to date and time ***/ + + typedef date-and-time { + type string { + pattern + '[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]+)?' + + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; + } + description + "The date-and-time type is a profile of the ISO 8601 + standard for representation of dates and times using the + Gregorian calendar. The profile is defined by the + date-time production in Section 5.6 of RFC 3339 and the + update defined in Section 2 of RFC 9557. The value of + 60 for seconds is allowed only in the case of leap seconds. + + The date-and-time type is compatible with the dateTime XML + schema dateTime type with the following notable exceptions: + + (a) The date-and-time type does not allow negative years. + + (b) The time-offset Z indicates that the date-and-time + value is reported in UTC and that the local time zone + reference point is unknown. The time-offset +00:00 + indicates that the date-and-time value is reported in + UTC and that the local time zone reference point is UTC + (see Section 2 of RFC 9557). + + This type is not equivalent to the DateAndTime textual + convention of the SMIv2 since RFC 3339 uses a different + separator between full-date and full-time and provides + higher resolution of time-secfrac. + + The canonical format for date-and-time values with a known + time 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 offset to UTC time will cause + date-and-time values to change accordingly. Such changes + might happen periodically if a server automatically follows + daylight saving time (DST) time zone offset changes. The + canonical format for date-and-time values reported in UTC + with an unknown local time zone offset SHOULD use the + time-offset Z and MAY use -00:00 for backwards + compatibility."; + reference + "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 + with Additional Information + RFC 2579: Textual Conventions for SMIv2 + XSD-TYPES: XML Schema Definition Language (XSD) 1.1 + Part 2: Datatypes"; + } + + typedef date { + type string { + pattern '[0-9]{4}-(1[0-2]|0[1-9])-(0[1-9]|[1-2][0-9]|3[0-1])' + + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; + } + description + "The date type represents a time-interval of the length + of a day, i.e., 24 hours. It includes an optional time + zone offset. + + The date type is compatible with the XML schema date + type with the following notable exceptions: + + (a) The date type does not allow negative years. + + (b) The time-offset Z indicates that the date value is + reported in UTC and that the local time zone reference + point is unknown. The time-offset +00:00 indicates that + the date value is reported in UTC and that the local + time zone reference point is UTC (see Section 2 of + RFC 9557). + + The canonical format for date values with a known time + 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 offset to UTC time will cause date values + to change accordingly. Such changes might happen periodically + if a server automatically follows daylight saving time + (DST) time zone offset changes. The canonical format for + date values reported in UTC with an unknown local time zone + offset uses the time-offset Z."; + reference + "RFC 3339: Date and Time on the Internet: Timestamps + RFC 9557: Date and Time on the Internet: Timestamps + with Additional Information + XSD-TYPES: XML Schema Definition Language (XSD) 1.1 + Part 2: Datatypes"; + } + + typedef date-no-zone { + type date { + pattern '[0-9]{4}-(1[0-2]|0[1-9])-(0[1-9]|[1-2][0-9]|3[0-1])'; + } + description + "The date-no-zone type represents a date without the optional + time zone offset information."; + } + + typedef time { + type string { + pattern + '(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))?'; + } + description + "The time type represents an instance of time of zero duration + that recurs every day. It includes an optional time zone + offset. The value of 60 for seconds is allowed only in the + case of leap seconds. + + The time type is compatible with the XML schema time + type with the following notable exception: + + (a) The time-offset Z indicates that the time value is + reported in UTC and that the local time zone reference + point is unknown. The time-offset +00:00 indicates that + the time value is reported in UTC and that the local + time zone reference point is UTC (see Section 2 of + RFC 9557). + + The canonical format for time values with a known time + 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 offset to UTC time will cause time values + to change accordingly. Such changes might happen periodically + if a server automatically follows daylight saving time + (DST) time zone offset changes. The canonical format for + time values reported in UTC with an unknown local time zone + offset uses the time-offset Z."; + reference + "RFC 3339: Date and Time on the Internet: Timestamps + RFC 9557: Date and Time on the Internet: Timestamps + with Additional Information + XSD-TYPES: XML Schema Definition Language (XSD) 1.1 + Part 2: Datatypes"; + } + + typedef time-no-zone { + type time { + pattern + '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:([0-5][0-9]|60)' + + '(\.[0-9]+)?'; + } + description + "The time-no-zone type represents a time without the optional + time zone offset information."; + } + + typedef hours32 { + type int32; + units "hours"; + description + "A period of time measured in units of hours. + + The maximum time period that can be expressed is in the + range [-89478485 days 08:00:00 to 89478485 days 07:00:00]. + + This type should be range-restricted in situations + where only non-negative time periods are desirable + (i.e., range '0..max')."; + } + + typedef minutes32 { + type int32; + units "minutes"; + description + "A period of time measured in units of minutes. + + The maximum time period that can be expressed is in the + range [-1491308 days 2:08:00 to 1491308 days 2:07:00]. + + This type should be range-restricted in situations + where only non-negative time periods are desirable + (i.e., range '0..max')."; + } + + typedef seconds32 { + type int32; + units "seconds"; + description + "A period of time measured in units of seconds. + + The maximum time period that can be expressed is in the + range [-24855 days 03:14:08 to 24855 days 03:14:07]. + + This type should be range-restricted in situations + where only non-negative time periods are desirable + (i.e., range '0..max')."; + } + + typedef centiseconds32 { + type int32; + units "centiseconds"; + description + "A period of time measured in units of 10^-2 seconds. + + The maximum time period that can be expressed is in the + range [-248 days 13:13:56 to 248 days 13:13:56]. + + This type should be range-restricted in situations + where only non-negative time periods are desirable + (i.e., range '0..max')."; + } + + typedef milliseconds32 { + type int32; + units "milliseconds"; + description + "A period of time measured in units of 10^-3 seconds. + + The maximum time period that can be expressed is in the + range [-24 days 20:31:23 to 24 days 20:31:23]. + + This type should be range-restricted in situations + where only non-negative time periods are desirable + (i.e., range '0..max')."; + } + + typedef microseconds32 { + type int32; + units "microseconds"; + description + "A period of time measured in units of 10^-6 seconds. + + The maximum time period that can be expressed is in the + range [-00:35:47 to 00:35:47]. + + This type should be range-restricted in situations + where only non-negative time periods are desirable + (i.e., range '0..max')."; + } + + typedef microseconds64 { + type int64; + units "microseconds"; + description + "A period of time measured in units of 10^-6 seconds. + + The maximum time period that can be expressed is in the + range [-106751991 days 04:00:54 to 106751991 days 04:00:54]. + + This type should be range-restricted in situations + where only non-negative time periods are desirable + (i.e., range '0..max')."; + } + + typedef nanoseconds32 { + type int32; + units "nanoseconds"; + description + "A period of time measured in units of 10^-9 seconds. + + The maximum time period that can be expressed is in the + range [-00:00:02 to 00:00:02]. + + This type should be range-restricted in situations + where only non-negative time periods are desirable + (i.e., range '0..max')."; + } + + typedef nanoseconds64 { + type int64; + units "nanoseconds"; + description + "A period of time measured in units of 10^-9 seconds. + + The maximum time period that can be expressed is in the + range [-106753 days 23:12:44 to 106752 days 0:47:16]. + + This type should be range-restricted in situations + where only non-negative time periods are desirable + (i.e., range '0..max')."; + } + + typedef timeticks { + type uint32; + description + "The timeticks type represents a non-negative integer that + represents the time, modulo 2^32 (4294967296 decimal), in + hundredths of a second between two epochs. When a schema + node is defined that uses this type, the description of + the schema node identifies both of the reference epochs. + + In the value set and its semantics, this type is equivalent + to the TimeTicks type of the SMIv2."; + reference + "RFC 2578: Structure of Management Information Version 2 + (SMIv2)"; + } + + typedef timestamp { + type timeticks; + description + "The timestamp type represents the value of an associated + timeticks schema node instance at which a specific occurrence + happened. The specific occurrence must be defined in the + description of any schema node defined using this type. When + the specific occurrence occurred prior to the last time the + associated timeticks schema node instance was zero, then the + timestamp value is zero. + + Note that this requires all timestamp values to be reset to + zero when the value of the associated timeticks schema node + instance reaches 497+ days and wraps around to zero. + + The associated timeticks schema node must be specified + in the description of any schema node using this type. + + In the value set and its semantics, this type is equivalent + to the TimeStamp textual convention of the SMIv2."; + reference + "RFC 2579: Textual Conventions for SMIv2"; + } + + /*** collection of generic address types ***/ + + typedef phys-address { + type string { + pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?'; + } + description + "Represents media- or physical-level addresses represented + as a sequence of octets, each octet represented by two + hexadecimal numbers. Octets are separated by colons. The + canonical representation uses lowercase characters. + + In the value set and its semantics, this type is equivalent + to the PhysAddress textual convention of the SMIv2."; + reference + "RFC 2579: Textual Conventions for SMIv2"; + } + + typedef mac-address { + type string { + pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}'; + } + description + "The mac-address type represents a 48-bit IEEE 802 Media + Access Control (MAC) address. The canonical representation + uses lowercase characters. Note that there are IEEE 802 MAC + addresses with a different length that this type cannot + represent. The phys-address type may be used to represent + physical addresses of varying length. + + In the value set and its semantics, this type is equivalent + to the MacAddress textual convention of the SMIv2."; + reference + "IEEE 802: IEEE Standard for Local and Metropolitan Area + Networks: Overview and Architecture + RFC 2579: Textual Conventions for SMIv2"; + } + + /*** collection of XML-specific types ***/ + + typedef xpath1.0 { + type string; + description + "This type represents an XPATH 1.0 expression. + + When a schema node is defined that uses this type, the + description of the schema node MUST specify the XPath + context in which the XPath expression is evaluated."; + reference + "XPATH: XML Path Language (XPath) Version 1.0"; + } + + /*** collection of string types ***/ + + typedef hex-string { + type string { + pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?'; + } + description + "A hexadecimal string with octets represented as hex digits + separated by colons. The canonical representation uses + lowercase characters."; + } + + typedef uuid { + type string { + 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}'; + } + description + "A Universally Unique IDentifier in the string representation + defined in RFC 9562. The canonical representation uses + lowercase characters. + + The following is an example of a UUID in string + representation: + f81d4fae-7dec-11d0-a765-00a0c91e6bf6. + "; + reference + "RFC 9562: Universally Unique IDentifiers (UUIDs)"; + } + + typedef dotted-quad { + type string { + 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])'; + } + description + "An unsigned 32-bit number expressed in the dotted-quad + notation, i.e., four octets written as decimal numbers + and separated with the '.' (full stop) character."; + } + + typedef language-tag { + type string; + description + "A language tag according to RFC 5646 (BCP 47). The + canonical representation uses lowercase characters. + + Values of this type must be well-formed language tags, + in conformance with the definition of well-formed tags + in BCP 47. Implementations MAY further limit the values + they accept to those permitted by a 'validating' + processor, as defined in BCP 47. + + The canonical representation of values of this type is + aligned with the SMIv2 LangTag textual convention for + language tags fitting the length constraints imposed + by the LangTag textual convention."; + reference + "RFC 5646: Tags for Identifying Languages + RFC 5131: A MIB Textual Convention for Language Tags"; + } + + /*** collection of YANG-specific types ***/ + + typedef yang-identifier { + type string { + length "1..max"; + pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*'; + } + description + "A YANG identifier string as defined by the 'identifier' + rule in Section 14 of RFC 7950. An identifier must + start with an alphabetic character or an underscore + followed by an arbitrary sequence of alphabetic or + numeric characters, underscores, hyphens, or dots. + + This definition conforms to YANG 1.1 defined in RFC + 7950. In RFC 6991, this definition excluded + all identifiers starting with any possible combination + of the lowercase or uppercase character sequence 'xml', + as required by YANG 1 defined in RFC 6020. If this type + is used in a YANG 1 context, then this restriction still + applies."; + reference + "RFC 7950: The YANG 1.1 Data Modeling Language + RFC 6991: Common YANG Data Types + RFC 6020: YANG - A Data Modeling Language for the + Network Configuration Protocol (NETCONF)"; + } +}