diff options
author | 2021-04-02 12:41:14 +0300 | |
---|---|---|
committer | 2021-04-07 09:17:23 +0000 | |
commit | 26effb23f559df0256327b8d37c865e023a41292 (patch) | |
tree | 14f4a596e0e5d6602d183a741d9de5911b126bbe /cps-service/src/test/resources/e2e/basic | |
parent | d138529fe66f39b17047091d7e54117845ba9b50 (diff) |
Fix xpath building for data nodes addressing YANG augmentation
Issue-ID: CPS-316
Change-Id: I8aa0960c2a6af2b8fe5bc2fb90efe36baee7a881
Signed-off-by: Ruslan Kashapov <ruslan.kashapov@pantheon.tech>
Diffstat (limited to 'cps-service/src/test/resources/e2e/basic')
-rwxr-xr-x | cps-service/src/test/resources/e2e/basic/ietf-inet-types.yang | 457 | ||||
-rwxr-xr-x | cps-service/src/test/resources/e2e/basic/ietf-yang-types.yang | 480 |
2 files changed, 0 insertions, 937 deletions
diff --git a/cps-service/src/test/resources/e2e/basic/ietf-inet-types.yang b/cps-service/src/test/resources/e2e/basic/ietf-inet-types.yang deleted file mode 100755 index 2f14270de..000000000 --- a/cps-service/src/test/resources/e2e/basic/ietf-inet-types.yang +++ /dev/null @@ -1,457 +0,0 @@ -module ietf-inet-types { - - namespace "urn:ietf:params:xml:ns:yang:ietf-inet-types"; - prefix "inet"; - - organization - "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; - - contact - "WG Web: <http://tools.ietf.org/wg/netmod/> - WG List: <mailto:netmod@ietf.org> - - WG Chair: David Kessens - <mailto:david.kessens@nsn.com> - - WG Chair: Juergen Schoenwaelder - <mailto:j.schoenwaelder@jacobs-university.de> - - Editor: Juergen Schoenwaelder - <mailto:j.schoenwaelder@jacobs-university.de>"; - - description - "This module contains a collection of generally useful derived - YANG data types for Internet addresses and related things. - - Copyright (c) 2013 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 Simplified BSD License - set forth in Section 4.c of the IETF Trust's Legal Provisions - Relating to IETF Documents - (http://trustee.ietf.org/license-info). - - This version of this YANG module is part of RFC 6991; see - the RFC itself for full legal notices."; - - revision 2013-07-15 { - description - "This revision adds the following new data types: - - ip-address-no-zone - - ipv4-address-no-zone - - 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 2460."; - } - } - 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 2460: 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 2460: 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. A current list of - all assignments is available from <http://www.iana.org/>. - - 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 793: Transmission Control Protocol - RFC 4960: Stream Control Transmission Protocol - RFC 4340: Datagram Congestion Control Protocol (DCCP) - RFC 4001: Textual Conventions for Internet Network Addresses"; - } - - /*** 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 inet:ipv4-address; - type inet: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])' - + '(%[\p{N}\p{L}]+)?'; - } - 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. - - 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])))' - + '(%[\p{N}\p{L}]+)?'; - 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. - - 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 inet:ipv4-address-no-zone; - type inet: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 inet: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."; - } - - typedef ipv6-address-no-zone { - type inet: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."; - 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-prefix { - type union { - type inet:ipv4-prefix; - type inet: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 address 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."; - } - - 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 address 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 IPv6 address should have all bits that do not belong - to the prefix set to zero. - - 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."; - 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. - - 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. It is designed to hold various types of - domain names, including names used for A or AAAA records - (host names) and other records, such as SRV records. Note - that Internet host names have a stricter syntax (described - in RFC 952) than the DNS recommendations in RFCs 1034 and - 1123, and that systems that want to store host names in - schema nodes using the domain-name type are recommended to - adhere to this stricter standard to ensure interoperability. - - 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 2782: A DNS RR for specifying the location of services - (DNS SRV) - RFC 5890: Internationalized Domain Names in Applications - (IDNA): Definitions and Document Framework"; - } - - typedef host { - type union { - type inet:ip-address; - type inet:domain-name; - } - description - "The host type represents either an IP address or a DNS - domain name."; - } - - typedef uri { - type string; - description - "The uri type represents a Uniform Resource Identifier - (URI) as defined by STD 66. - - 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. - - 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)"; - } - -} diff --git a/cps-service/src/test/resources/e2e/basic/ietf-yang-types.yang b/cps-service/src/test/resources/e2e/basic/ietf-yang-types.yang deleted file mode 100755 index 371a091d1..000000000 --- a/cps-service/src/test/resources/e2e/basic/ietf-yang-types.yang +++ /dev/null @@ -1,480 +0,0 @@ -module ietf-yang-types { - - namespace "urn:ietf:params:xml:ns:yang:ietf-yang-types"; - prefix "yang"; - - organization - "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; - - contact - "WG Web: <http://tools.ietf.org/wg/netmod/> - WG List: <mailto:netmod@ietf.org> - - WG Chair: David Kessens - <mailto:david.kessens@nsn.com> - - WG Chair: Juergen Schoenwaelder - <mailto:j.schoenwaelder@jacobs-university.de> - - Editor: Juergen Schoenwaelder - <mailto:j.schoenwaelder@jacobs-university.de>"; - - description - "This module contains a collection of generally useful derived - YANG data types. - - Copyright (c) 2013 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 Simplified BSD License - set forth in Section 4.c of the IETF Trust's Legal Provisions - Relating to IETF Documents - (http://trustee.ietf.org/license-info). - - This version of this YANG module is part of RFC 6991; see - the RFC itself for full legal notices."; - - revision 2013-07-15 { - description - "This revision adds the following new data types: - - yang-identifier - - hex-string - - uuid - - 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 creation 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 yang:counter32; - default "0"; - description - "The zero-based-counter32 type represents a counter32 - that has the defined 'initial' value zero. - - A schema node of 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 - 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 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 creation 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 yang:counter64; - default "0"; - description - "The zero-based-counter64 type represents a counter64 that - has the defined 'initial' value zero. - - - - - A schema node of 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 - 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 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]\d*))))' - + '(\.(0|([1-9]\d*)))*'; - } - 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 '\d*(\.\d*){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)"; - } - - typedef yang-identifier { - type string { - length "1..max"; - pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*'; - pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*'; - } - description - "A YANG identifier string as defined by the 'identifier' - rule in Section 12 of RFC 6020. 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. - - A YANG identifier MUST NOT start with any possible - combination of the lowercase or uppercase character - sequence 'xml'."; - reference - "RFC 6020: YANG - A Data Modeling Language for the Network - Configuration Protocol (NETCONF)"; - } - - /*** collection of types related to date and time***/ - - typedef date-and-time { - type string { - pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?' - + '(Z|[\+\-]\d{2}:\d{2})'; - } - 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. - - The date-and-time type is compatible with the dateTime XML - schema type with the following notable exceptions: - - (a) The date-and-time type does not allow negative years. - - (b) The date-and-time time-offset -00:00 indicates an unknown - time zone (see RFC 3339) while -00:00 and +00:00 and Z - all represent the same time zone in dateTime. - - (c) The canonical format (see below) of data-and-time values - differs from the canonical format used by the dateTime XML - schema type, which requires all times to be in UTC using - the time-offset 'Z'. - - 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 with an unknown time zone (usually - referring to the notion of local time) uses the time-offset - -00:00."; - reference - "RFC 3339: Date and Time on the Internet: Timestamps - RFC 2579: Textual Conventions for SMIv2 - XSD-TYPES: XML Schema Part 2: Datatypes Second Edition"; - } - - 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 yang:timeticks; - description - "The timestamp type represents the value of an associated - timeticks schema node 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 attribute 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 - attribute 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 an IEEE 802 MAC address. - The canonical representation uses lowercase characters. - - 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."; - } -} |