diff --git a/yang-models/_3gpp-common-ep-rp.yang b/yang-models/_3gpp-common-ep-rp.yang index 3b4d22dd97c390af97e3d8078daedb03d17e1126..a3c14b50f0230bedf8c6e5592db6ab9021e9920a 100755 --- a/yang-models/_3gpp-common-ep-rp.yang +++ b/yang-models/_3gpp-common-ep-rp.yang @@ -12,7 +12,7 @@ module _3gpp-common-ep-rp { description "Common/basic class/grouping to be inherited/reused. This IOC represents an end point of a link used across a reference point between two network entities. - Copyright 2023, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, + Copyright 2025, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC). All rights reserved."; reference "3GPP TS 28.622 @@ -23,6 +23,7 @@ module _3gpp-common-ep-rp { 3GPP TS 28.620 Umbrella Information Model (UIM)"; + revision 2025-10-01 { reference CR-0578 ; } revision 2023-09-18 { reference CR-0271 ; } revision 2020-06-08 { reference "CR-0092"; } @@ -49,11 +50,12 @@ module _3gpp-common-ep-rp { config false; type types3gpp:DistinguishedName; } + + uses meas3gpp:SupportedPerfMetricGroupGrp; } grouping EP_Common { uses EP_RPGrp; - uses meas3gpp:SupportedPerfMetricGroupGrp; list localAddress { description "Local IP address and VLAN ID."; key "ipAddress vlanId"; diff --git a/yang-models/_3gpp-common-trace.yang b/yang-models/_3gpp-common-trace.yang index cbcf5b179aad55ff78b7c65b6e3e42e098e4e275..38df834ebf4406e550fd69f57f6c4d13c9667879 100755 --- a/yang-models/_3gpp-common-trace.yang +++ b/yang-models/_3gpp-common-trace.yang @@ -25,6 +25,7 @@ module _3gpp-common-trace { Integration Reference Point (IRP); Information Service (IS)" ; + revision 2025-10-01 { reference "CR-0578" ; } revision 2025-08-07 { reference "CR-0551 CR-0552 CR-0562" ; } revision 2025-05-07 { reference "CR-0532 CR-0536 CR-0540" ; } revision 2025-02-07 { reference "CR-0504" ; } @@ -1585,7 +1586,7 @@ module _3gpp-common-trace { reference "clause 5.10.38 of TS 32.422"; } - list areaConfigurationForNeighCells { + list areaConfigurationForNeighCell { when '../../../jobType = "LOGGED_MDT_ONLY" or' + ' ../../../jobType = "IMMEDIATE_MDT_AND_LOGGED_MDT"'; key "idx"; @@ -1731,7 +1732,7 @@ module _3gpp-common-trace { trsrPrefixLength defines the size of base TRSR prefix."; reference "Clause 5.10 of 3GPP TS 32.422."; leaf idx { type uint32 ; } - uses trace3gpp:trsrPrefixCfgGrp ; + uses trace3gpp:TrsrPrefixCfgGrp ; } } @@ -1786,8 +1787,8 @@ module _3gpp-common-trace { } } - grouping trsrPrefixCfgGrp { - leaf trstPrefix { + grouping TrsrPrefixCfgGrp { + leaf trsrPrefix { type string; mandatory true; description "A 2 byte Octet String. This is the base TRSR prefix"; diff --git a/yang-models/_3gpp-common-yang-types.yang b/yang-models/_3gpp-common-yang-types.yang index bba864e2836d03deb76227e5011b19e97053e9a6..85be05055048c245d3f6e2ae599cd89d725475db 100755 --- a/yang-models/_3gpp-common-yang-types.yang +++ b/yang-models/_3gpp-common-yang-types.yang @@ -17,6 +17,7 @@ module _3gpp-common-yang-types { reference "3GPP TS 28.623"; + revision 2025-10-01 { reference "CR-0578" ; } revision 2025-08-31 { reference "CR-0551 CR-0556 CR-0562"; } revision 2025-02-19 { reference CR-0512; } revision 2025-02-07 { reference CR-0492; } @@ -103,7 +104,7 @@ module _3gpp-common-yang-types { } typedef FullTime { - type yang:time-with-zone-offset; + type yang:time; } grouping DayInYearGrp { diff --git a/yang-models/_3gpp-nr-nrm-ep.yang b/yang-models/_3gpp-nr-nrm-ep.yang index 60bc8091fcc1b17b7b30dca317f29792c6872d3e..755af3fead459450e4572b15e0fef572a8ecb7ce 100755 --- a/yang-models/_3gpp-nr-nrm-ep.yang +++ b/yang-models/_3gpp-nr-nrm-ep.yang @@ -9,6 +9,7 @@ module _3gpp-nr-nrm-ep { import _3gpp-nr-nrm-gnbcucpfunction { prefix gnbcucp3gpp; } import _3gpp-nr-nrm-gnbcuupfunction { prefix gnbcuup3gpp; } import _3gpp-nr-nrm-gnbdufunction { prefix gnbdu3gpp; } + import _3gpp-common-yang-types { prefix types3gpp ; } organization "3GPP SA5"; contact "https://www.3gpp.org/DynaReport/TSG-WG--S5--officials.htm?Itemid=464"; @@ -19,6 +20,7 @@ module _3gpp-nr-nrm-ep { TTA, TTC). All rights reserved."; reference "3GPP TS 28.541 5G Network Resource Model (NRM)"; + revision 2025-10-01 { reference CR-1617 ; } revision 2025-05-06 { reference "CR-1526 CR-1527" ; } // common for R18, R19 revision 2023-09-18 { reference CR-1043 ; } revision 2022-01-07 { reference CR-0643; } @@ -47,6 +49,11 @@ module _3gpp-nr-nrm-ep { uses eprp3gpp:EP_Common; } + grouping EP_F1CGrp { + description "Attributes of IOC EP_F1U"; + uses eprp3gpp:EP_Common; + } + grouping EP_F1CSubtree { list EP_F1C { description "Represents the local end point of the control plane @@ -55,11 +62,24 @@ module _3gpp-nr-nrm-ep { key id; uses top3gpp:Top_Grp; container attributes { - uses eprp3gpp:EP_Common; + uses EP_F1CGrp; } } } + grouping EP_F1UGrp { + description "Attributes of IOC EP_F1U"; + uses eprp3gpp:EP_Common; + + leaf-list epTransportRef { + type types3gpp:DistinguishedName; + config false; + description "This parameter specifies a list of transport level EPs + associated with the application level EP (i.e. EP_N3 or EP_NgU or + EP_F1U) or network slice subnet."; + } + } + grouping EP_F1USubtree { list EP_F1U { description "Represents the local end point of the user plane @@ -68,7 +88,7 @@ module _3gpp-nr-nrm-ep { key id; uses top3gpp:Top_Grp; container attributes { - uses eprp3gpp:EP_Common; + uses EP_F1UGrp; } } } diff --git a/yang-models/_3gpp-nr-nrm-iabfunction.yang b/yang-models/_3gpp-nr-nrm-iabfunction.yang index 12592ba498c406202cd9e263dde2aa917d8414b5..80004ae190bb6c58bc9579e2ff7bb6bef9e59769 100644 --- a/yang-models/_3gpp-nr-nrm-iabfunction.yang +++ b/yang-models/_3gpp-nr-nrm-iabfunction.yang @@ -18,6 +18,7 @@ module _3gpp-nr-nrm-iabfunction { reference "3GPP TS 28.541; 3GPP TS 28.314; 3GPP TS 28.315; 3GPP TS 33.310, IETF RFC 9811"; + revision 2025-10-01 { reference "CR-1617" ; } revision 2025-08-15 { reference "CR-1598"; } grouping CaraConfigurationGrp { @@ -170,10 +171,11 @@ module _3gpp-nr-nrm-iabfunction { uses LocationInfoGrp; } } - grouping IabSubTree { + + grouping IABSubTree { description "Contains classes that manage IAB function management"; - list IAB { + list IAB { description "IAB-node architecture is specified in TS 38.401. This IOC defines the configuration information for the IAB management"; @@ -191,7 +193,7 @@ module _3gpp-nr-nrm-iabfunction { augment /me3gpp:ManagedElement { if-feature IABUnderManagedElement; - uses IabSubTree; + uses IABSubTree; } feature IABUnderSubNetwork { @@ -200,6 +202,6 @@ module _3gpp-nr-nrm-iabfunction { augment /subnet3gpp:SubNetwork { if-feature IABUnderSubNetwork; - uses IabSubTree; + uses IABSubTree; } } \ No newline at end of file diff --git a/yang-models/external-yams/ietf-inet-types.yang b/yang-models/external-yams/ietf-inet-types.yang index 8101ea4bc5978aa27e86fbcaf41f6513ce86aedc..a7da0952342a163ea835d574d0c2bba36cd52be0 100755 --- a/yang-models/external-yams/ietf-inet-types.yang +++ b/yang-models/external-yams/ietf-inet-types.yang @@ -16,14 +16,13 @@ module ietf-inet-types { 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) 2022 IETF Trust and the persons identified as + 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 @@ -36,13 +35,14 @@ module ietf-inet-types { This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; - revision 2023-01-23 { + 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 @@ -64,7 +64,6 @@ module ietf-inet-types { reference "RFC 6991: Common YANG Data Types"; } - revision 2010-09-24 { description "Initial revision."; @@ -171,10 +170,7 @@ module ietf-inet-types { "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. If IPv6 extension headers are present, then the - protocol number type represents the upper layer protocol - number, i.e., the number of the last next header' field - of the IPv6 extension headers. + header. Protocol numbers are assigned by IANA. The current list of all assignments is available from ."; @@ -183,6 +179,19 @@ module ietf-inet-types { 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 { @@ -219,8 +228,8 @@ module ietf-inet-types { typedef ip-address { type union { - type inet:ipv4-address; - type inet:ipv6-address; + type ipv4-address; + type ipv6-address; } description "The ip-address type represents an IP address and is IP @@ -236,12 +245,16 @@ module ietf-inet-types { 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])' - + '(%[A-Za-z0-9][A-Za-z0-9\-\._~/]*)?'; + + '(%.+)?'; } 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. + 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 @@ -268,6 +281,10 @@ module ietf-inet-types { "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 @@ -288,8 +305,8 @@ module ietf-inet-types { typedef ip-address-no-zone { type union { - type inet:ipv4-address-no-zone; - type inet:ipv6-address-no-zone; + type ipv4-address-no-zone; + type ipv6-address-no-zone; } description "The ip-address-no-zone type represents an IP address and is @@ -302,23 +319,25 @@ module ietf-inet-types { } typedef ipv4-address-no-zone { - type inet:ipv4-address { + type ipv4-address { pattern '[0-9\.]*'; } description - "An IPv4 address without a zone index. This type, derived from - ipv4-address, may be used in situations where the zone is known - from the context and hence no zone index is needed."; + "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 inet:ipv6-address { + type ipv6-address { pattern '[0-9a-fA-F:\.]*'; } description - "An IPv6 address without a zone index. This type, derived from - ipv6-address, may be used in situations where the zone is known - from the context and hence no zone index is needed."; + "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 @@ -328,8 +347,8 @@ module ietf-inet-types { typedef ip-address-link-local { type union { - type inet:ipv4-address-link-local; - type inet:ipv6-address-link-local; + type ipv4-address-link-local; + type ipv6-address-link-local; } description "The ip-address-link-local type represents a link-local IP @@ -361,8 +380,8 @@ module ietf-inet-types { typedef ip-prefix { type union { - type inet:ipv4-prefix; - type inet:ipv6-prefix; + type ipv4-prefix; + type ipv6-prefix; } description "The ip-prefix type represents an IP prefix and is IP @@ -381,7 +400,6 @@ module ietf-inet-types { "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. @@ -436,8 +454,8 @@ module ietf-inet-types { typedef ip-address-and-prefix { type union { - type inet:ipv4-address-and-prefix; - type inet:ipv6-address-and-prefix; + type ipv4-address-and-prefix; + type ipv6-address-and-prefix; } description "The ip-address-and-prefix type represents an IP address and @@ -454,7 +472,7 @@ module ietf-inet-types { } description "The ipv4-address-and-prefix type represents an IPv4 - address and an associated ipv4 prefix. + 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. @@ -476,7 +494,7 @@ module ietf-inet-types { } description "The ipv6-address-and-prefix type represents an IPv6 - address and an associated ipv4 prefix. + 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. @@ -516,6 +534,7 @@ module ietf-inet-types { 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 @@ -544,7 +563,8 @@ module ietf-inet-types { (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"; + (IDNA): Definitions and Document Framework + RFC 9499: DNS Terminology"; } typedef host-name { @@ -565,14 +585,13 @@ module ietf-inet-types { typedef host { type union { - type inet:ip-address; - type inet:host-name; + 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+.-]*:.*'; @@ -583,11 +602,13 @@ module ietf-inet-types { 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. All unnecessary - percent-encoding is removed, and all case-insensitive - characters are set to lowercase except for hexadecimal - digits, which are normalized to uppercase as described in - Section 6.2.2.1. + 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 @@ -616,25 +637,29 @@ module ietf-inet-types { typedef email-address { type string { - pattern '(([a-zA-Z0-9!#$%&'+"'"+'*+/=?\^_`{|}~-]+' - + '(\.[a-zA-Z0-9!#$%&'+"'"+'*+/=?\^_`{|}~-]+)*)|' - + '("[a-zA-Z0-9!#$%&'+"'"+'()*+,./\[\]\^_`{|}~-]*"))' - + '@' - + '(([a-zA-Z0-9!#$%&'+"'"+'*+/=?\^_`{|}~-]+' - + '(\.[a-zA-Z0-9!#$%&'+"'"+'*+/=?\^_`{|}~-]+)*)|' - + '\[[a-zA-Z0-9!"#$%&'+"'"+'()*+,./:;<=>?@\^_`{|}~-]+\])'; + pattern '.+@.+'; } description - "The email-address type represents an email address as - defined as addr-spec in RFC 5322 section 3.4.1 except - that obs-local-part, obs-domain and obs-qtext of the - quoted-string are not supported. - - The email-address type uses US-ASCII characters. The - canonical format of the domain part of an email-address - uses lowercase US-ASCII characters."; + "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 5322: Internet Message Format + RFC 5890: Internationalized Domain Names in Applications + (IDNA): Definitions and Document Framework + RFC 6531: SMTP Extension for Internationalized Email"; } } diff --git a/yang-models/external-yams/ietf-yang-schema-mount@2019-01-14.yang b/yang-models/external-yams/ietf-yang-schema-mount.yang old mode 100755 new mode 100644 similarity index 100% rename from yang-models/external-yams/ietf-yang-schema-mount@2019-01-14.yang rename to yang-models/external-yams/ietf-yang-schema-mount.yang diff --git a/yang-models/external-yams/ietf-yang-types.yang b/yang-models/external-yams/ietf-yang-types.yang index 39e390cba870289d46e7185101f0d7c81253a11f..c67167fd00c3807146d552f09443f4f3c050ea73 100644 --- a/yang-models/external-yams/ietf-yang-types.yang +++ b/yang-models/external-yams/ietf-yang-types.yang @@ -23,7 +23,7 @@ module ietf-yang-types { described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. - Copyright (c) 2022 IETF Trust and the persons identified as + 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 @@ -36,12 +36,12 @@ module ietf-yang-types { This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; - revision 2023-01-23 { + revision 2025-06-23 { description "This revision adds the following new data types: - - yang:date-with-zone-offset + - yang:date - yang:date-no-zone - - yang:time-with-zone-offset + - yang:time - yang:time-no-zone - yang:hours32 - yang:minutes32 @@ -53,8 +53,11 @@ module ietf-yang-types { - yang:nanoseconds32 - yang:nanoseconds64 - yang:language-tag - The yang-identifier definition has been aligned with YANG 1.1. - Several pattern statements have been improved."; + 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"; } @@ -111,20 +114,21 @@ module ietf-yang-types { } typedef zero-based-counter32 { - type yang:counter32; + type counter32; default "0"; description "The zero-based-counter32 type represents a counter32 that has the defined 'initial' value zero. - A schema node instance of this type will be set to zero (0) + + 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 schema node - instance of 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 + 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. @@ -167,22 +171,22 @@ module ietf-yang-types { } typedef zero-based-counter64 { - type yang:counter64; + type counter64; default "0"; description "The zero-based-counter64 type represents a counter64 that has the defined 'initial' value zero. - A schema node instance of this type will be set to zero (0) + 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 schema node - instance of 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 + 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. @@ -208,7 +212,6 @@ module ietf-yang-types { 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 @@ -301,27 +304,30 @@ module ietf-yang-types { 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](\.[0-9]+)?' - + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; + 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. + 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 -00:00 indicates that the date-and-time + (b) The time-offset Z indicates that the date-and-time value is reported in UTC and that the local time zone - reference point is unknown. The time-offsets +00:00 and Z - both indicate that the date-and-time value is reported in - UTC and that the local time reference point is UTC (see RFC - 3339 section 4.3). + 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 @@ -335,34 +341,39 @@ module ietf-yang-types { 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 with an unknown time zone (usually - referring to the notion of local time) uses the time-offset - -00:00, i.e., date-and-time values must be reported in UTC."; + 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-with-zone-offset { + 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))?'; + 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. + 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 -00:00 indicates that the date value is - reported in UTC and that the local time zone reference point - is unknown. The time-offsets +00:00 and Z both indicate that - the date value is reported in UTC and that the local time - reference point is UTC (see RFC 3339 section 4.3). + (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 @@ -371,17 +382,18 @@ module ietf-yang-types { 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 with an unknown time zone (usually referring - to the notion of local time) uses the time-offset -00:00, - i.e., date values must be reported in UTC."; + 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-with-zone-offset { + type date { pattern '[0-9]{4}-(1[0-2]|0[1-9])-(0[1-9]|[1-2][0-9]|3[0-1])'; } description @@ -389,23 +401,26 @@ module ietf-yang-types { time zone offset information."; } - typedef time-with-zone-offset { + typedef time { type string { - pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.[0-9]+)?' - + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?'; + 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. + 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 -00:00 indicates that the time value is - reported in UTC and that the local time zone reference point - is unknown. The time-offsets +00:00 and Z both indicate that - the time value is reported in UTC and that the local time - reference point is UTC (see RFC 3339 section 4.3). + (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 @@ -414,18 +429,20 @@ module ietf-yang-types { 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 with an unknown time zone (usually referring - to the notion of local time) uses the time-offset -00:00, - i.e., time values must be reported in UTC."; + 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-with-zone-offset { - pattern '(0[0-9]|1[0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.[0-9]+)?'; + 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 @@ -575,7 +592,7 @@ module ietf-yang-types { } typedef timestamp { - type yang:timeticks; + type timeticks; description "The timestamp type represents the value of an associated timeticks schema node instance at which a specific occurrence @@ -621,9 +638,12 @@ module ietf-yang-types { pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}'; } description - "The mac-address type represents an IEEE 802 MAC address. - The canonical representation uses lowercase characters. - + "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 @@ -724,7 +744,7 @@ module ietf-yang-types { numeric characters, underscores, hyphens, or dots. This definition conforms to YANG 1.1 defined in RFC - 7950. An earlier version of this definition did exclude + 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