2 ietf-inet-types.yang|"module ietf-inet-types {
4 namespace \"urn:ietf:params:xml:ns:yang:ietf-inet-types\";
8 \"IETF NETMOD (NETCONF Data Modeling Language) Working Group\";
11 \"WG Web: <http://tools.ietf.org/wg/netmod/>
12 WG List: <mailto:netmod@ietf.org>
14 WG Chair: David Kessens
15 <mailto:david.kessens@nsn.com>
17 WG Chair: Juergen Schoenwaelder
18 <mailto:j.schoenwaelder@jacobs-university.de>
20 Editor: Juergen Schoenwaelder
21 <mailto:j.schoenwaelder@jacobs-university.de>\";
24 \"This module contains a collection of generally useful derived
25 YANG data types for Internet addresses and related things.
27 Copyright (c) 2013 IETF Trust and the persons identified as
28 authors of the code. All rights reserved.
30 Redistribution and use in source and binary forms, with or
31 without modification, is permitted pursuant to, and subject
32 to the license terms contained in, the Simplified BSD License
33 set forth in Section 4.c of the IETF Trust''s Legal Provisions
34 Relating to IETF Documents
35 (http://trustee.ietf.org/license-info).
37 This version of this YANG module is part of RFC 6991; see
38 the RFC itself for full legal notices.\";
42 \"This revision adds the following new data types:
44 - ipv4-address-no-zone
45 - ipv6-address-no-zone\";
47 \"RFC 6991: Common YANG Data Types\";
52 \"Initial revision.\";
54 \"RFC 6021: Common YANG Data Types\";
57 /*** collection of types related to protocol fields ***/
64 \"An unknown or unspecified version of the Internet
70 \"The IPv4 protocol as defined in RFC 791.\";
75 \"The IPv6 protocol as defined in RFC 2460.\";
79 \"This value represents the version of the IP protocol.
81 In the value set and its semantics, this type is equivalent
82 to the InetVersion textual convention of the SMIv2.\";
84 \"RFC 791: Internet Protocol
85 RFC 2460: Internet Protocol, Version 6 (IPv6) Specification
86 RFC 4001: Textual Conventions for Internet Network Addresses\";
94 \"The dscp type represents a Differentiated Services Code Point
95 that may be used for marking packets in a traffic stream.
96 In the value set and its semantics, this type is equivalent
97 to the Dscp textual convention of the SMIv2.\";
99 \"RFC 3289: Management Information Base for the Differentiated
100 Services Architecture
101 RFC 2474: Definition of the Differentiated Services Field
102 (DS Field) in the IPv4 and IPv6 Headers
103 RFC 2780: IANA Allocation Guidelines For Values In
104 the Internet Protocol and Related Headers\";
107 typedef ipv6-flow-label {
109 range \"0..1048575\";
112 \"The ipv6-flow-label type represents the flow identifier or Flow
113 Label in an IPv6 packet header that may be used to
114 discriminate traffic flows.
116 In the value set and its semantics, this type is equivalent
117 to the IPv6FlowLabel textual convention of the SMIv2.\";
119 \"RFC 3595: Textual Conventions for IPv6 Flow Label
120 RFC 2460: Internet Protocol, Version 6 (IPv6) Specification\";
123 typedef port-number {
128 \"The port-number type represents a 16-bit port number of an
129 Internet transport-layer protocol such as UDP, TCP, DCCP, or
130 SCTP. Port numbers are assigned by IANA. A current list of
131 all assignments is available from <http://www.iana.org/>.
133 Note that the port number value zero is reserved by IANA. In
134 situations where the value zero does not make sense, it can
135 be excluded by subtyping the port-number type.
136 In the value set and its semantics, this type is equivalent
137 to the InetPortNumber textual convention of the SMIv2.\";
139 \"RFC 768: User Datagram Protocol
140 RFC 793: Transmission Control Protocol
141 RFC 4960: Stream Control Transmission Protocol
142 RFC 4340: Datagram Congestion Control Protocol (DCCP)
143 RFC 4001: Textual Conventions for Internet Network Addresses\";
146 /*** collection of types related to autonomous systems ***/
151 \"The as-number type represents autonomous system numbers
152 which identify an Autonomous System (AS). An AS is a set
153 of routers under a single technical administration, using
154 an interior gateway protocol and common metrics to route
155 packets within the AS, and using an exterior gateway
156 protocol to route packets to other ASes. IANA maintains
157 the AS number space and has delegated large parts to the
160 Autonomous system numbers were originally limited to 16
161 bits. BGP extensions have enlarged the autonomous system
162 number space to 32 bits. This type therefore uses an uint32
163 base type without a range restriction in order to support
164 a larger autonomous system number space.
166 In the value set and its semantics, this type is equivalent
167 to the InetAutonomousSystemNumber textual convention of
170 \"RFC 1930: Guidelines for creation, selection, and registration
171 of an Autonomous System (AS)
172 RFC 4271: A Border Gateway Protocol 4 (BGP-4)
173 RFC 4001: Textual Conventions for Internet Network Addresses
174 RFC 6793: BGP Support for Four-Octet Autonomous System (AS)
178 /*** collection of types related to IP addresses and hostnames ***/
182 type inet:ipv4-address;
183 type inet:ipv6-address;
186 \"The ip-address type represents an IP address and is IP
187 version neutral. The format of the textual representation
188 implies the IP version. This type supports scoped addresses
189 by allowing zone identifiers in the address format.\";
191 \"RFC 4007: IPv6 Scoped Address Architecture\";
194 typedef ipv4-address {
197 ''(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5]).){3}''
198 + ''([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])''
199 + ''(%[p{N}p{L}]+)?'';
202 \"The ipv4-address type represents an IPv4 address in
203 dotted-quad notation. The IPv4 address may include a zone
204 index, separated by a % sign.
206 The zone index is used to disambiguate identical address
207 values. For link-local addresses, the zone index will
208 typically be the interface index number or the name of an
209 interface. If the zone index is not present, the default
210 zone of the device will be used.
212 The canonical format for the zone index is the numerical
216 typedef ipv6-address {
218 pattern ''((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}''
219 + ''((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|''
220 + ''(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9]).){3}''
221 + ''(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))''
222 + ''(%[p{N}p{L}]+)?'';
223 pattern ''(([^:]+:){6}(([^:]+:[^:]+)|(.*..*)))|''
224 + ''((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)''
228 \"The ipv6-address type represents an IPv6 address in full,
229 mixed, shortened, and shortened-mixed notation. The IPv6
230 address may include a zone index, separated by a % sign.
232 The zone index is used to disambiguate identical address
233 values. For link-local addresses, the zone index will
234 typically be the interface index number or the name of an
235 interface. If the zone index is not present, the default
236 zone of the device will be used.
238 The canonical format of IPv6 addresses uses the textual
239 representation defined in Section 4 of RFC 5952. The
240 canonical format for the zone index is the numerical
241 format as described in Section 11.2 of RFC 4007.\";
243 \"RFC 4291: IP Version 6 Addressing Architecture
244 RFC 4007: IPv6 Scoped Address Architecture
245 RFC 5952: A Recommendation for IPv6 Address Text
249 typedef ip-address-no-zone {
251 type inet:ipv4-address-no-zone;
252 type inet:ipv6-address-no-zone;
255 \"The ip-address-no-zone type represents an IP address and is
256 IP version neutral. The format of the textual representation
257 implies the IP version. This type does not support scoped
258 addresses since it does not allow zone identifiers in the
261 \"RFC 4007: IPv6 Scoped Address Architecture\";
264 typedef ipv4-address-no-zone {
265 type inet:ipv4-address {
269 \"An IPv4 address without a zone index. This type, derived from
270 ipv4-address, may be used in situations where the zone is
271 known from the context and hence no zone index is needed.\";
274 typedef ipv6-address-no-zone {
275 type inet:ipv6-address {
276 pattern ''[0-9a-fA-F:.]*'';
279 \"An IPv6 address without a zone index. This type, derived from
280 ipv6-address, may be used in situations where the zone is
281 known from the context and hence no zone index is needed.\";
283 \"RFC 4291: IP Version 6 Addressing Architecture
284 RFC 4007: IPv6 Scoped Address Architecture
285 RFC 5952: A Recommendation for IPv6 Address Text
291 type inet:ipv4-prefix;
292 type inet:ipv6-prefix;
295 \"The ip-prefix type represents an IP prefix and is IP
296 version neutral. The format of the textual representations
297 implies the IP version.\";
300 typedef ipv4-prefix {
303 ''(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5]).){3}''
304 + ''([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])''
305 + ''/(([0-9])|([1-2][0-9])|(3[0-2]))'';
308 \"The ipv4-prefix type represents an IPv4 address prefix.
309 The prefix length is given by the number following the
310 slash character and must be less than or equal to 32.
312 A prefix length value of n corresponds to an IP address
313 mask that has n contiguous 1-bits from the most
314 significant bit (MSB) and all other bits set to 0.
316 The canonical format of an IPv4 prefix has all bits of
317 the IPv4 address set to zero that are not part of the
321 typedef ipv6-prefix {
323 pattern ''((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}''
324 + ''((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|''
325 + ''(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9]).){3}''
326 + ''(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))''
327 + ''(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))'';
328 pattern ''(([^:]+:){6}(([^:]+:[^:]+)|(.*..*)))|''
329 + ''((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)''
333 \"The ipv6-prefix type represents an IPv6 address prefix.
334 The prefix length is given by the number following the
335 slash character and must be less than or equal to 128.
337 A prefix length value of n corresponds to an IP address
338 mask that has n contiguous 1-bits from the most
339 significant bit (MSB) and all other bits set to 0.
341 The IPv6 address should have all bits that do not belong
342 to the prefix set to zero.
344 The canonical format of an IPv6 prefix has all bits of
345 the IPv6 address set to zero that are not part of the
346 IPv6 prefix. Furthermore, the IPv6 address is represented
347 as defined in Section 4 of RFC 5952.\";
349 \"RFC 5952: A Recommendation for IPv6 Address Text
353 /*** collection of domain name and URI types ***/
355 typedef domain-name {
359 ''((([a-zA-Z0-9_]([a-zA-Z0-9-_]){0,61})?[a-zA-Z0-9].)*''
360 + ''([a-zA-Z0-9_]([a-zA-Z0-9-_]){0,61})?[a-zA-Z0-9].?)''
364 \"The domain-name type represents a DNS domain name. The
365 name SHOULD be fully qualified whenever possible.
367 Internet domain names are only loosely specified. Section
368 3.5 of RFC 1034 recommends a syntax (modified in Section
369 2.1 of RFC 1123). The pattern above is intended to allow
370 for current practice in domain name use, and some possible
371 future expansion. It is designed to hold various types of
372 domain names, including names used for A or AAAA records
373 (host names) and other records, such as SRV records. Note
374 that Internet host names have a stricter syntax (described
375 in RFC 952) than the DNS recommendations in RFCs 1034 and
376 1123, and that systems that want to store host names in
377 schema nodes using the domain-name type are recommended to
378 adhere to this stricter standard to ensure interoperability.
380 The encoding of DNS names in the DNS protocol is limited
381 to 255 characters. Since the encoding consists of labels
382 prefixed by a length bytes and there is a trailing NULL
383 byte, only 253 characters can appear in the textual dotted
386 The description clause of schema nodes using the domain-name
387 type MUST describe when and how these names are resolved to
388 IP addresses. Note that the resolution of a domain-name value
389 may require to query multiple DNS records (e.g., A for IPv4
390 and AAAA for IPv6). The order of the resolution process and
391 which DNS record takes precedence can either be defined
392 explicitly or may depend on the configuration of the
395 Domain-name values use the US-ASCII encoding. Their canonical
396 format uses lowercase US-ASCII characters. Internationalized
397 domain names MUST be A-labels as per RFC 5890.\";
399 \"RFC 952: DoD Internet Host Table Specification
400 RFC 1034: Domain Names - Concepts and Facilities
401 RFC 1123: Requirements for Internet Hosts -- Application
403 RFC 2782: A DNS RR for specifying the location of services
405 RFC 5890: Internationalized Domain Names in Applications
406 (IDNA): Definitions and Document Framework\";
411 type inet:ip-address;
412 type inet:domain-name;
415 \"The host type represents either an IP address or a DNS
422 \"The uri type represents a Uniform Resource Identifier
423 (URI) as defined by STD 66.
425 Objects using the uri type MUST be in US-ASCII encoding,
426 and MUST be normalized as described by RFC 3986 Sections
427 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary
428 percent-encoding is removed, and all case-insensitive
429 characters are set to lowercase except for hexadecimal
430 digits, which are normalized to uppercase as described in
433 The purpose of this normalization is to help provide
434 unique URIs. Note that this normalization is not
435 sufficient to provide uniqueness. Two URIs that are
436 textually distinct after this normalization may still be
439 Objects using the uri type may restrict the schemes that
440 they permit. For example, ''data:'' and ''urn:'' schemes
441 might not be appropriate.
443 A zero-length URI is not a valid URI. This can be used to
444 express ''URI absent'' where required.
446 In the value set and its semantics, this type is equivalent
447 to the Uri SMIv2 textual convention defined in RFC 5017.\";
449 \"RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
450 RFC 3305: Report from the Joint W3C/IETF URI Planning Interest
451 Group: Uniform Resource Identifiers (URIs), URLs,
452 and Uniform Resource Names (URNs): Clarifications
454 RFC 5017: MIB Textual Conventions for Uniform Resource
455 Identifiers (URIs)\";
458 }"|417a7b14944f6236ad0e2b1ef956158c050cff9b74e3561ca80af32d11be240b
459 cps-ran-schema-model2021-01-28.yang|"module cps-ran-schema-model {
461 namespace \"org:onap:ccsdk:features:sdnr:northbound:cps-ran-schema-model\";
464 import ietf-inet-types {
467 import ietf-yang-types {
472 \"Open Network Automation Platform - ONAP
473 <https://www.onap.org>\";
477 <mailto:sandeep.shah@ibm.com>
479 Swaminathan Seetharaman
480 <mailto:swaminathan.seetharaman@wipro.com>\";
482 \"This module contains a collection of YANG definitions for capturing
483 relationships among managed elements of the radio access Network
484 to be stored in ONAP CPS platform.
486 Copyright 2020-2021 IBM.
488 Licensed under the Apache License, Version 2.0 (the ''License'');
489 you may not use this file except in compliance with the License.
490 You may obtain a copy of the License at
492 http://www.apache.org/licenses/LICENSE-2.0
494 Unless required by applicable law or agreed to in writing, software
495 distributed under the License is distributed on an ''AS IS'' BASIS,
496 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
497 See the License for the specific language governing permissions and
498 limitations under the License.\";
500 revision 2021-01-28 {
502 \"CPS RAN Network YANG Model for ONAP/O-RAN POC\";
504 \"https://wiki.onap.org/display/DW/E2E+Network+Slicing+Use+Case+in+R7+Guilin\";
523 \"It describes whether or not the resource is actively in
524 use at a specific instant, and if so, whether or not it has spare
525 capacity for additional users at that instant. The value is READ-ONLY.\";
527 \"ITU T Recommendation X.731\";
533 \"The mobile country code consists of three decimal digits,
534 The first digit of the mobile country code identifies the geographic
535 region (the digits 1 and 8 are not used):\";
537 \"3GPP TS 23.003 subclause 2.2 and 12.1\";
543 \"The mobile network code consists of two or three
544 decimal digits (for example: MNC of 001 is not the same as MNC of 01)\";
546 \"3GPP TS 23.003 subclause 2.2 and 12.1\";
552 \"NR Cell Identity. The NCI shall be of fixed length of 36 bits
553 and shall be coded using full hexadecimal representation.
554 The exact coding of the NCI is the responsibility of each PLMN operator\";
559 typedef OperationalState {
564 \"The resource is totally inoperable.\";
569 \"The resource is partially or fully operable.\";
575 \"3GPP TS 28.625 and ITU-T X.731\";
578 typedef AvailabilityStatus {
647 \"Single Network Slice Selection Assistance Information.\";
649 \"TS 23.501 clause 5.15.2\";
663 \"Physical Cell Identity (PCI) of the NR cell.\";
665 \"TS 36.211 subclause 6.11\";
670 range \"0..16777215\";
673 \"Tracking Area Code\";
675 \"TS 23.003 clause 19.4.2.3\";
678 typedef AmfRegionId {
683 \"clause 2.10.1 of 3GPP TS 23.003\";
691 \"clause 2.10.1 of 3GPP TS 23.003\";
699 \"clause 2.10.1 of 3GPP TS 23.003\";
702 // type definitions especially for core NFs
791 typedef NotificationType {
797 enum N2_INFORMATION {
801 enum LOCATION_NOTIFICATION {
815 \"Latest known load information of the NF, percentage \";
818 typedef N1MessageClass {
841 typedef N2InformationClass {
876 typedef UeMobilityLevel {
886 enum RESTRICTED_MOBILITY {
890 enum FULLY_MOBILITY {
901 typedef ResourceSharingLevel {
918 typedef TxDirection {
939 typedef DistinguishedName { // TODO is this equivalent to TS 32.300 ?
942 \"Represents the international standard for the representation
943 of Distinguished Name (RFC 4512).
944 The format of the DistinguishedName REGEX is:
945 {AttributeType = AttributeValue}
947 AttributeType consists of alphanumeric and hyphen (OIDs not allowed).
948 All other characters are restricted.
949 The Attribute value cannot contain control characters or the
950 following characters : \ > < ; \" + , (Comma) and White space
951 The Attribute value can contain the following characters if they
952 are excaped : \ > < ; \" + , (Comma) and White space
953 The Attribute value can contain control characters if its an escaped
954 double digit hex number.
956 UID=nobody@example.com,DC=example,DC=com
957 CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US\";
959 \"RFC 4512 Lightweight Directory Access Protocol (LDAP):
960 Directory Information Models\";
961 } // recheck regexp it doesn''t handle posix [:cntrl:]
963 typedef QOffsetRange {
987 typedef CyclicPrefix {
1004 \"The PLMNInfo data type define a S-NSSAI member in a specific PLMNId, and it have
1005 two attributes PLMNId and S-NSSAI (PLMNId, S-NSSAI). The PLMNId represents a data type that
1006 is comprised of mcc (mobile country code) and mnc (mobile network code), (See TS 23.003
1007 subclause 2.2 and 12.1) and S-NSSAI represents an data type, that is comprised of an SST
1008 (Slice/Service type) and an optional SD (Slice Differentiator) field, (See TS 23.003 [13]).\";
1013 description \"List of sNSSAIs\";
1017 grouping ManagedNFProfile {
1019 \"Defines profile for managed NF\";
1034 \"This parameter defines profile for managed NF.
1035 The format of the NF Instance ID shall be a
1036 Universally Unique Identifier (UUID) version 4,
1037 as described in IETF RFC 4122 \";
1044 \"Type of the Network Function\";
1050 \"Host address of a NF\";
1055 \"This parameter defines NF Specific Service authorization
1056 information. It shall include the NF type (s) and NF realms/origins
1057 allowed to consume NF Service(s) of NF Service Producer.\";
1064 \"Information about the location of the NF instance
1065 (e.g. geographic location, data center) defined by operator\";
1073 \"This parameter defines static capacity information
1074 in the range of 0-65535, expressed as a weight relative to other
1075 NF instances of the same type; if capacity is also present in the
1076 nfServiceList parameters, those will have precedence over this value.\";
1083 \"This parameter defines identity of the group that is
1084 served by the NF instance.
1085 May be config false or true depending on the ManagedFunction.
1086 Config=true for Udrinfo. Config=false for UdmInfo and AusfInfo.
1087 Shall be present if ../nfType = UDM or AUSF or UDR. \";
1091 leaf-list supportedDataSetIds {
1111 \"List of supported data sets in the UDR instance.
1112 May be present if ../nfType = UDR\";
1116 leaf-list smfServingAreas {
1119 \"Defines the SMF service area(s) the UPF can serve.
1120 Shall be present if ../nfType = UPF\";
1127 \"This parameter defines Priority (relative to other NFs
1128 of the same type) in the range of 0-65535, to be used for NF selection;
1129 lower values indicate a higher priority. If priority is also present
1130 in the nfServiceList parameters, those will have precedence over
1131 this value. Shall be present if ../nfType = AMF \";
1157 grouping AmfIdentifier {
1159 \"The AMFI is constructed from an AMF Region ID,
1160 an AMF Set ID and an AMF Pointer.
1161 The AMF Region ID identifies the region,
1162 the AMF Set ID uniquely identifies the AMF Set within the AMF Region, and
1163 the AMF Pointer uniquely identifies the AMF within the AMF Set. \";
1181 grouping DefaultNotificationSubscription {
1184 leaf notificationType {
1185 type NotificationType;
1194 leaf n1MessageClass {
1195 type N1MessageClass;
1199 leaf n2InformationClass {
1200 type N2InformationClass;
1206 grouping Ipv4AddressRange {
1210 type inet:ipv4-address;
1215 type inet:ipv4-address;
1221 grouping Ipv6PrefixRange {
1225 type inet:ipv6-prefix;
1230 type inet:ipv6-prefix;
1236 grouping AddressWithVlan {
1240 type inet:ip-address;
1251 grouping ManagedElementGroup {
1253 \"Abstract class representing telecommunications resources.\";
1255 type DistinguishedName;
1257 \"Provides naming context and splits the DN into a DN Prefix and Local DN\";
1262 \"A user-friendly name of this object.\";
1268 \"The physical location (e.g. an address) of an entity\";
1270 leaf-list managedBy {
1271 type DistinguishedName;
1274 \"Relates to the role played by ManagementSystem\";
1276 leaf-list managedElementTypeList {
1281 \"The type of functionality provided by the ManagedElement.
1282 It may represent one ME functionality or a combination of
1283 Two examples of allowed values are:
1287 } // Managed Element grouping
1289 grouping NearRTRICGroup {
1291 \"Abstract class representing Near RT RIC.\";
1293 type DistinguishedName;
1295 \"Provides naming context and splits the DN into a DN Prefix and Local DN\";
1300 \"A user-friendly name of this object.\";
1306 \"The physical location (e.g. an address) of an entity\";
1309 type int64 { range \"0..4294967295\"; }
1311 description \"Identifies a gNB within a PLMN. The gNB Identifier (gNB ID)
1312 is part of the NR Cell Identifier (NCI) of the gNB cells.\";
1313 reference \"gNB ID in 3GPP TS 38.300, Global gNB ID in 3GPP TS 38.413\";
1319 description \"The PLMNInfoList is a list of PLMNInfo data type. It defines which PLMNs that can be served by the nearRTRIC.\";
1321 list RRMPolicyRatio {
1328 container attributes {
1329 uses RRMPolicyRatioGroup;
1331 description \" The RRMPolicyRatio IOC is one realization of a RRMPolicy_ IOC, see the
1332 inheritance in Figure 4.2.1.2-1. This RRM framework allows adding new policies, both
1333 standardized (like RRMPolicyRatio) or as vendor specific, by inheriting from the
1334 abstract RRMPolicy_ IOC. For details see subclause 4.3.36.\";
1337 } // Near RT RIC grouping
1341 grouping Configuration{
1342 leaf configParameter{
1344 description \"Type of the configuration parameter\";
1348 description \"Identifies the configuration to be done for the network elements under the NearRTRIC\";
1354 grouping GNBDUFunctionGroup {
1356 \"Represents the GNBDUFunction IOC.\";
1362 range \"0..4294967295\";
1367 \"Identifies a gNB within a PLMN. The gNB Identifier (gNB ID)
1368 is part of the NR Cell Identifier (NCI) of the gNB cells.\";
1370 \"gNB ID in 3GPP TS 38.300, Global gNB ID in 3GPP TS 38.413\";
1378 \"Indicates the number of bits for encoding the gNB ID.\";
1380 \"gNB ID in 3GPP TS 38.300, Global gNB ID in 3GPP TS 38.413\";
1384 range \"0..68719476735\";
1388 \"Uniquely identifies the DU at least within a gNB.\";
1397 \"Identifies the Distributed Unit of an NR node\";
1401 list RRMPolicyRatio {
1408 container attributes {
1409 uses RRMPolicyRatioGroup;
1411 description \" The RRMPolicyRatio IOC is one realization of a RRMPolicy_ IOC, see the
1412 inheritance in Figure 4.2.1.2-1. This RRM framework allows adding new policies, both
1413 standardized (like RRMPolicyRatio) or as vendor specific, by inheriting from the
1414 abstract RRMPolicy_ IOC. For details see subclause 4.3.36.\";
1418 grouping NRCellDUGroup {
1420 \"Represents the NRCellDU IOC.\";
1423 list RRMPolicyRatio {
1430 container attributes {
1431 uses RRMPolicyRatioGroup;
1433 description \" The RRMPolicyRatio IOC is one realization of a RRMPolicy_ IOC, see the
1434 inheritance in Figure 4.2.1.2-1. This RRM framework allows adding new policies, both
1435 standardized (like RRMPolicyRatio) or as vendor specific, by inheriting from the
1436 abstract RRMPolicy_ IOC. For details see subclause 4.3.36.\";
1444 \"Identifies an NR cell of a gNB. Together with the
1445 corresponding gNB identifier in forms the NR Cell Identity (NCI).\";
1447 \"NCI in 3GPP TS 38.300\";
1453 \"The PLMNInfoList is a list of PLMNInfo data type. It defines which PLMNs that
1454 can be served by the NR cell, and which S-NSSAIs that can be supported by the NR cell for
1455 corresponding PLMN in case of network slicing feature is supported. The plMNId of the first
1456 entry of the list is the PLMNId used to construct the nCGI for the NR cell.\";
1465 \"The Physical Cell Identity (PCI) of the NR cell.\";
1472 \"The common 5GS Tracking Area Code for the PLMNs.\";
1474 \"3GPP TS 23.003, 3GPP TS 38.473\";
1478 grouping rRMPolicyMemberGroup {
1485 \"This data type represents an RRM Policy member that will be part of a
1486 rRMPolicyMemberList. A RRMPolicyMember is defined by its pLMNId and sNSSAI (S-NSSAI).
1487 The members in a rRMPolicyMemberList are assigned a specific amount of RRM resources
1488 based on settings in RRMPolicy.\";
1492 grouping RRMPolicyRatioGroup {
1494 uses RRMPolicy_Group; // Inherits RRMPolicy_
1499 description \"The type of the quota which allows to allocate resources as
1500 strictly usable for defined slice(s) (strict quota) or allows that
1501 resources to be used by other slice(s) when defined slice(s) do not
1502 need them (float quota).\";
1505 leaf rRMPolicyMaxRatio {
1509 description \"The RRM policy setting the maximum percentage of radio
1510 resources to be allocated to the corresponding S-NSSAI list. This
1511 quota can be strict or float quota. Strict quota means resources are
1512 not allowed for other sNSSAIs even when they are not used by the
1513 defined sNSSAIList. Float quota resources can be used by other sNSSAIs
1514 when the defined sNSSAIList do not need them. Value 0 indicates that
1515 there is no maximum limit.\";
1518 leaf rRMPolicyMinRatio {
1522 description \"The RRM policy setting the minimum percentage of radio
1523 resources to be allocated to the corresponding S-NSSAI list. This
1524 quota can be strict or float quota. Strict quota means resources are
1525 not allowed for other sNSSAIs even when they are not used by the
1526 defined sNSSAIList. Float quota resources can be used by other sNSSAIs
1527 when the defined sNSSAIList do not need them. Value 0 indicates that
1528 there is no minimum limit.\";
1530 leaf rRMPolicyDedicatedRatio {
1533 description \"Dedicated Ration.\";
1535 description \"Represents the RRMPolicyRatio concrete IOC.\";
1539 grouping sNSSAIConfig{
1542 description \"s-NSSAI of a network slice.\";
1543 reference \"3GPP TS 23.003\";
1547 description \"status of s-NSSAI\";
1551 key \"configParameter\";
1552 description \"List of configurations to be done at the network elements\";
1556 grouping RRMPolicy_Group {
1558 \"This IOC represents the properties of an abstract RRMPolicy. The RRMPolicy_ IOC
1559 needs to be subclassed to be instantiated. It defines two attributes apart from those
1560 inherited from Top IOC, the resourceType attribute defines type of resource (PRB, RRC
1561 connected users, DRB usage etc.) and the rRMPolicyMemberList attribute defines the
1562 RRMPolicyMember(s)that are subject to this policy. An RRM resource (defined in resourceType
1563 attribute) is located in NRCellDU, NRCellCU, GNBDUFunction, GNBCUCPFunction or in
1564 GNBCUUPFunction. The RRMPolicyRatio IOC is one realization of a RRMPolicy_ IOC, see the
1565 inheritance in TS 28.541 Figure 4.2.1.2-1. This RRM framework allows adding new policies,
1566 both standardized (like RRMPolicyRatio) or as vendor specific, by inheriting from the
1567 abstract RRMPolicy_ IOC.\";
1572 \"The resourceType attribute defines type of resource (PRB, RRC connected users,
1573 DRB usage etc.) that is subject to policy. Valid values are ''PRB'', ''RRC'' or ''DRB''\";
1575 list rRMPolicyMemberList {
1583 \"It represents the list of RRMPolicyMember (s) that the managed object
1584 is supporting. A RRMPolicyMember <<dataType>> include the PLMNId <<dataType>>
1585 and S-NSSAI <<dataType>>.\";
1586 uses rRMPolicyMemberGroup;
1590 grouping GNBCUUPFunctionGroup {
1592 \"Represents the GNBCUUPFunction IOC.\";
1596 list RRMPolicyRatio {
1603 container attributes {
1604 uses RRMPolicyRatioGroup;
1606 description \" The RRMPolicyRatio IOC is one realization of a RRMPolicy_ IOC, see the
1607 inheritance in Figure 4.2.1.2-1. This RRM framework allows adding new policies, both
1608 standardized (like RRMPolicyRatio) or as vendor specific, by inheriting from the
1609 abstract RRMPolicy_ IOC. For details see subclause 4.3.36.\";
1613 range \"0..68719476735\";
1618 \"Identifies the gNB-CU-UP at least within a gNB-CU-CP\";
1620 \"''gNB-CU-UP ID'' in subclause 9.3.1.15 of 3GPP TS 38.463\";
1624 range \"0..4294967295\";
1628 \"Indicates the number of bits for encoding the gNB Id.\";
1630 \"gNB Id in 3GPP TS 38.300, Global gNB ID in 3GPP TS 38.413\";
1635 \"The PLMNInfoList is a list of PLMNInfo data type. It defines which PLMNs that
1636 can be served by the GNBCUUPFunction and which S-NSSAIs can be supported by the
1637 GNBCUUPFunction for corresponding PLMN in case of network slicing feature is supported\";
1642 grouping GNBCUCPFunctionGroup {
1644 \"Represents the GNBCUCPFunction IOC.\";
1647 list RRMPolicyRatio {
1654 container attributes {
1655 uses RRMPolicyRatioGroup;
1657 description \" The RRMPolicyRatio IOC is one realization of a RRMPolicy_ IOC, see the
1658 inheritance in Figure 4.2.1.2-1. This RRM framework allows adding new policies, both
1659 standardized (like RRMPolicyRatio) or as vendor specific, by inheriting from the
1660 abstract RRMPolicy_ IOC. For details see subclause 4.3.36.\";
1664 range \"0..4294967295\";
1668 \"Identifies a gNB within a PLMN. The gNB Identifier (gNB ID)
1669 is part of the NR Cell Identifier (NCI) of the gNB cells.\";
1671 \"gNB ID in 3GPP TS 38.300, Global gNB ID in 3GPP TS 38.413\";
1679 \"Indicates the number of bits for encoding the gNB ID.\";
1681 \"gNB ID in 3GPP TS 38.300, Global gNB ID in 3GPP TS 38.413\";
1689 \"Identifies the Central Unit of an gNB.\";
1698 \"The PLMN identifier to be used as part of the global RAN
1704 grouping NRCellCUGroup {
1706 \"Represents the NRCellCU IOC.\";
1715 \"Identifies an NR cell of a gNB. Together with corresponding
1716 gNB ID it forms the NR Cell Identifier (NCI).\";
1722 \"The PLMNInfoList is a list of PLMNInfo data type. It defines which PLMNs
1723 that can be served by the NR cell, and which S-NSSAIs that can be supported by the
1724 NR cell for corresponding PLMN in case of network slicing feature is supported.\";
1726 // Note: Whether the attribute pLMNId in the pLMNInfo can be writable depends on the implementation.
1728 list RRMPolicyRatio {
1735 container attributes {
1736 uses RRMPolicyRatioGroup;
1738 description \" The RRMPolicyRatio IOC is one realization of a RRMPolicy_ IOC, see the
1739 inheritance in Figure 4.2.1.2-1. This RRM framework allows adding new policies, both
1740 standardized (like RRMPolicyRatio) or as vendor specific, by inheriting from the
1741 abstract RRMPolicy_ IOC. For details see subclause 4.3.36.\";
1743 } // grouping NRCellCUGroup
1745 grouping NRCellRelationGroup {
1747 \"Represents the NRCellRelation IOC.\";
1753 \"Target NR Cell Identifier. It consists of NR Cell
1754 Identifier (NCI) and Physical Cell Identifier of the target NR cell
1756 "|436fef591eba7f38d1a0c5e3cbd3c122f01ab41dfab37cc5a9cbca1ed53b29fb
1757 ietf-yang-types.yang|"module ietf-yang-types {
1759 namespace \"urn:ietf:params:xml:ns:yang:ietf-yang-types\";
1763 \"IETF NETMOD (NETCONF Data Modeling Language) Working Group\";
1766 \"WG Web: <http://tools.ietf.org/wg/netmod/>
1767 WG List: <mailto:netmod@ietf.org>
1769 WG Chair: David Kessens
1770 <mailto:david.kessens@nsn.com>
1772 WG Chair: Juergen Schoenwaelder
1773 <mailto:j.schoenwaelder@jacobs-university.de>
1775 Editor: Juergen Schoenwaelder
1776 <mailto:j.schoenwaelder@jacobs-university.de>\";
1779 \"This module contains a collection of generally useful derived
1782 Copyright (c) 2013 IETF Trust and the persons identified as
1783 authors of the code. All rights reserved.
1785 Redistribution and use in source and binary forms, with or
1786 without modification, is permitted pursuant to, and subject
1787 to the license terms contained in, the Simplified BSD License
1788 set forth in Section 4.c of the IETF Trust''s Legal Provisions
1789 Relating to IETF Documents
1790 (http://trustee.ietf.org/license-info).
1792 This version of this YANG module is part of RFC 6991; see
1793 the RFC itself for full legal notices.\";
1795 revision 2013-07-15 {
1797 \"This revision adds the following new data types:
1803 \"RFC 6991: Common YANG Data Types\";
1806 revision 2010-09-24 {
1808 \"Initial revision.\";
1810 \"RFC 6021: Common YANG Data Types\";
1813 /*** collection of counter and gauge types ***/
1818 \"The counter32 type represents a non-negative integer
1819 that monotonically increases until it reaches a
1820 maximum value of 2^32-1 (4294967295 decimal), when it
1821 wraps around and starts increasing again from zero.
1823 Counters have no defined ''initial'' value, and thus, a
1824 single value of a counter has (in general) no information
1825 content. Discontinuities in the monotonically increasing
1826 value normally occur at re-initialization of the
1827 management system, and at other times as specified in the
1828 description of a schema node using this type. If such
1829 other times can occur, for example, the creation of
1830 a schema node of type counter32 at times other than
1831 re-initialization, then a corresponding schema node
1832 should be defined, with an appropriate type, to indicate
1833 the last discontinuity.
1835 The counter32 type should not be used for configuration
1836 schema nodes. A default statement SHOULD NOT be used in
1837 combination with the type counter32.
1839 In the value set and its semantics, this type is equivalent
1840 to the Counter32 type of the SMIv2.\";
1842 \"RFC 2578: Structure of Management Information Version 2
1846 typedef zero-based-counter32 {
1847 type yang:counter32;
1850 \"The zero-based-counter32 type represents a counter32
1851 that has the defined ''initial'' value zero.
1853 A schema node of this type will be set to zero (0) on creation
1854 and will thereafter increase monotonically until it reaches
1855 a maximum value of 2^32-1 (4294967295 decimal), when it
1856 wraps around and starts increasing again from zero.
1858 Provided that an application discovers a new schema node
1859 of this type within the minimum time to wrap, it can use the
1860 ''initial'' value as a delta. It is important for a management
1861 station to be aware of this minimum time and the actual time
1862 between polls, and to discard data if the actual time is too
1863 long or there is no defined minimum time.
1865 In the value set and its semantics, this type is equivalent
1866 to the ZeroBasedCounter32 textual convention of the SMIv2.\";
1868 \"RFC 4502: Remote Network Monitoring Management Information
1875 \"The counter64 type represents a non-negative integer
1876 that monotonically increases until it reaches a
1877 maximum value of 2^64-1 (18446744073709551615 decimal),
1878 when it wraps around and starts increasing again from zero.
1880 Counters have no defined ''initial'' value, and thus, a
1881 single value of a counter has (in general) no information
1882 content. Discontinuities in the monotonically increasing
1883 value normally occur at re-initialization of the
1884 management system, and at other times as specified in the
1885 description of a schema node using this type. If such
1886 other times can occur, for example, the creation of
1887 a schema node of type counter64 at times other than
1888 re-initialization, then a corresponding schema node
1889 should be defined, with an appropriate type, to indicate
1890 the last discontinuity.
1892 The counter64 type should not be used for configuration
1893 schema nodes. A default statement SHOULD NOT be used in
1894 combination with the type counter64.
1896 In the value set and its semantics, this type is equivalent
1897 to the Counter64 type of the SMIv2.\";
1899 \"RFC 2578: Structure of Management Information Version 2
1903 typedef zero-based-counter64 {
1904 type yang:counter64;
1907 \"The zero-based-counter64 type represents a counter64 that
1908 has the defined ''initial'' value zero.
1913 A schema node of this type will be set to zero (0) on creation
1914 and will thereafter increase monotonically until it reaches
1915 a maximum value of 2^64-1 (18446744073709551615 decimal),
1916 when it wraps around and starts increasing again from zero.
1918 Provided that an application discovers a new schema node
1919 of this type within the minimum time to wrap, it can use the
1920 ''initial'' value as a delta. It is important for a management
1921 station to be aware of this minimum time and the actual time
1922 between polls, and to discard data if the actual time is too
1923 long or there is no defined minimum time.
1925 In the value set and its semantics, this type is equivalent
1926 to the ZeroBasedCounter64 textual convention of the SMIv2.\";
1928 \"RFC 2856: Textual Conventions for Additional High Capacity
1935 \"The gauge32 type represents a non-negative integer, which
1936 may increase or decrease, but shall never exceed a maximum
1937 value, nor fall below a minimum value. The maximum value
1938 cannot be greater than 2^32-1 (4294967295 decimal), and
1939 the minimum value cannot be smaller than 0. The value of
1940 a gauge32 has its maximum value whenever the information
1941 being modeled is greater than or equal to its maximum
1942 value, and has its minimum value whenever the information
1943 being modeled is smaller than or equal to its minimum value.
1944 If the information being modeled subsequently decreases
1945 below (increases above) the maximum (minimum) value, the
1946 gauge32 also decreases (increases).
1948 In the value set and its semantics, this type is equivalent
1949 to the Gauge32 type of the SMIv2.\";
1951 \"RFC 2578: Structure of Management Information Version 2
1958 \"The gauge64 type represents a non-negative integer, which
1959 may increase or decrease, but shall never exceed a maximum
1960 value, nor fall below a minimum value. The maximum value
1961 cannot be greater than 2^64-1 (18446744073709551615), and
1962 the minimum value cannot be smaller than 0. The value of
1963 a gauge64 has its maximum value whenever the information
1964 being modeled is greater than or equal to its maximum
1965 value, and has its minimum value whenever the information
1966 being modeled is smaller than or equal to its minimum value.
1967 If the information being modeled subsequently decreases
1968 below (increases above) the maximum (minimum) value, the
1969 gauge64 also decreases (increases).
1971 In the value set and its semantics, this type is equivalent
1972 to the CounterBasedGauge64 SMIv2 textual convention defined
1975 \"RFC 2856: Textual Conventions for Additional High Capacity
1979 /*** collection of identifier-related types ***/
1981 typedef object-identifier {
1983 pattern ''(([0-1](.[1-3]?[0-9]))|(2.(0|([1-9]d*))))''
1984 + ''(.(0|([1-9]d*)))*'';
1987 \"The object-identifier type represents administratively
1988 assigned names in a registration-hierarchical-name tree.
1990 Values of this type are denoted as a sequence of numerical
1991 non-negative sub-identifier values. Each sub-identifier
1992 value MUST NOT exceed 2^32-1 (4294967295). Sub-identifiers
1993 are separated by single dots and without any intermediate
1996 The ASN.1 standard restricts the value space of the first
1997 sub-identifier to 0, 1, or 2. Furthermore, the value space
1998 of the second sub-identifier is restricted to the range
1999 0 to 39 if the first sub-identifier is 0 or 1. Finally,
2000 the ASN.1 standard requires that an object identifier
2001 has always at least two sub-identifiers. The pattern
2002 captures these restrictions.
2004 Although the number of sub-identifiers is not limited,
2005 module designers should realize that there may be
2006 implementations that stick with the SMIv2 limit of 128
2009 This type is a superset of the SMIv2 OBJECT IDENTIFIER type
2010 since it is not restricted to 128 sub-identifiers. Hence,
2011 this type SHOULD NOT be used to represent the SMIv2 OBJECT
2012 IDENTIFIER type; the object-identifier-128 type SHOULD be
2015 \"ISO9834-1: Information technology -- Open Systems
2016 Interconnection -- Procedures for the operation of OSI
2017 Registration Authorities: General procedures and top
2018 arcs of the ASN.1 Object Identifier tree\";
2021 typedef object-identifier-128 {
2022 type object-identifier {
2023 pattern ''d*(.d*){1,127}'';
2026 \"This type represents object-identifiers restricted to 128
2029 In the value set and its semantics, this type is equivalent
2030 to the OBJECT IDENTIFIER type of the SMIv2.\";
2032 \"RFC 2578: Structure of Management Information Version 2
2036 typedef yang-identifier {
2039 pattern ''[a-zA-Z_][a-zA-Z0-9-_.]*'';
2040 pattern ''.|..|[^xX].*|.[^mM].*|..[^lL].*'';
2043 \"A YANG identifier string as defined by the ''identifier''
2044 rule in Section 12 of RFC 6020. An identifier must
2045 start with an alphabetic character or an underscore
2046 followed by an arbitrary sequence of alphabetic or
2047 numeric characters, underscores, hyphens, or dots.
2049 A YANG identifier MUST NOT start with any possible
2050 combination of the lowercase or uppercase character
2051 sequence ''xml''.\";
2053 \"RFC 6020: YANG - A Data Modeling Language for the Network
2054 Configuration Protocol (NETCONF)\";
2057 /*** collection of types related to date and time***/
2059 typedef date-and-time {
2061 pattern ''d{4}-d{2}-d{2}Td{2}:d{2}:d{2}(.d+)?''
2062 + ''(Z|[+-]d{2}:d{2})'';
2065 \"The date-and-time type is a profile of the ISO 8601
2066 standard for representation of dates and times using the
2067 Gregorian calendar. The profile is defined by the
2068 date-time production in Section 5.6 of RFC 3339.
2070 The date-and-time type is compatible with the dateTime XML
2071 schema type with the following notable exceptions:
2073 (a) The date-and-time type does not allow negative years.
2075 (b) The date-and-time time-offset -00:00 indicates an unknown
2076 time zone (see RFC 3339) while -00:00 and +00:00 and Z
2077 all represent the same time zone in dateTime.
2079 (c) The canonical format (see below) of data-and-time values
2080 differs from the canonical format used by the dateTime XML
2081 schema type, which requires all times to be in UTC using
2082 the time-offset ''Z''.
2084 This type is not equivalent to the DateAndTime textual
2085 convention of the SMIv2 since RFC 3339 uses a different
2086 separator between full-date and full-time and provides
2087 higher resolution of time-secfrac.
2089 The canonical format for date-and-time values with a known time
2090 zone uses a numeric time zone offset that is calculated using
2091 the device''s configured known offset to UTC time. A change of
2092 the device''s offset to UTC time will cause date-and-time values
2093 to change accordingly. Such changes might happen periodically
2094 in case a server follows automatically daylight saving time
2095 (DST) time zone offset changes. The canonical format for
2096 date-and-time values with an unknown time zone (usually
2097 referring to the notion of local time) uses the time-offset
2100 \"RFC 3339: Date and Time on the Internet: Timestamps
2101 RFC 2579: Textual Conventions for SMIv2
2102 XSD-TYPES: XML Schema Part 2: Datatypes Second Edition\";
2108 \"The timeticks type represents a non-negative integer that
2109 represents the time, modulo 2^32 (4294967296 decimal), in
2110 hundredths of a second between two epochs. When a schema
2111 node is defined that uses this type, the description of
2112 the schema node identifies both of the reference epochs.
2114 In the value set and its semantics, this type is equivalent
2115 to the TimeTicks type of the SMIv2.\";
2117 \"RFC 2578: Structure of Management Information Version 2
2122 type yang:timeticks;
2124 \"The timestamp type represents the value of an associated
2125 timeticks schema node at which a specific occurrence
2126 happened. The specific occurrence must be defined in the
2127 description of any schema node defined using this type. When
2128 the specific occurrence occurred prior to the last time the
2129 associated timeticks attribute was zero, then the timestamp
2130 value is zero. Note that this requires all timestamp values
2131 to be reset to zero when the value of the associated timeticks
2132 attribute reaches 497+ days and wraps around to zero.
2134 The associated timeticks schema node must be specified
2135 in the description of any schema node using this type.
2137 In the value set and its semantics, this type is equivalent
2138 to the TimeStamp textual convention of the SMIv2.\";
2140 \"RFC 2579: Textual Conventions for SMIv2\";
2143 /*** collection of generic address types ***/
2145 typedef phys-address {
2147 pattern ''([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?'';
2154 \"Represents media- or physical-level addresses represented
2155 as a sequence octets, each octet represented by two hexadecimal
2156 numbers. Octets are separated by colons. The canonical
2157 representation uses lowercase characters.
2159 In the value set and its semantics, this type is equivalent
2160 to the PhysAddress textual convention of the SMIv2.\";
2162 \"RFC 2579: Textual Conventions for SMIv2\";
2165 typedef mac-address {
2167 pattern ''[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}'';
2170 \"The mac-address type represents an IEEE 802 MAC address.
2171 The canonical representation uses lowercase characters.
2173 In the value set and its semantics, this type is equivalent
2174 to the MacAddress textual convention of the SMIv2.\";
2176 \"IEEE 802: IEEE Standard for Local and Metropolitan Area
2177 Networks: Overview and Architecture
2178 RFC 2579: Textual Conventions for SMIv2\";
2181 /*** collection of XML-specific types ***/
2186 \"This type represents an XPATH 1.0 expression.
2188 When a schema node is defined that uses this type, the
2189 description of the schema node MUST specify the XPath
2190 context in which the XPath expression is evaluated.\";
2192 \"XPATH: XML Path Language (XPath) Version 1.0\";
2195 /*** collection of string types ***/
2197 typedef hex-string {
2199 pattern ''([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?'';
2202 \"A hexadecimal string with octets represented as hex digits
2203 separated by colons. The canonical representation uses
2204 lowercase characters.\";
2209 pattern ''[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-''
2210 + ''[0-9a-fA-F]{4}-[0-9a-fA-F]{12}'';
2213 \"A Universally Unique IDentifier in the string representation
2214 defined in RFC 4122. The canonical representation uses
2215 lowercase characters.
2217 The following is an example of a UUID in string representation:
2218 f81d4fae-7dec-11d0-a765-00a0c91e6bf6
2221 \"RFC 4122: A Universally Unique IDentifier (UUID) URN
2225 typedef dotted-quad {
2228 ''(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5]).){3}''
2229 + ''([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'';
2232 \"An unsigned 32-bit number expressed in the dotted-quad
2233 notation, i.e., four octets written as decimal numbers
2234 and separated with the ''.'' (full stop) character.\";
2236 }"|25516798613f862ad20831e59ba02b75ecdc9c6f5547ed5d90bda76143bf0112