diff --git a/common-dependencies/example1.xml b/common-dependencies/example1.xml new file mode 100644 index 0000000..2f4594c --- /dev/null +++ b/common-dependencies/example1.xml @@ -0,0 +1,105 @@ +{ + "yang-library:yang-library": { + "yang-packages:package": [ + { + "name": "vendor-schema", + "version": "2.1.0", + "module": [ + { + "name": "vendor-interfaces", + "revision": "2.2.0", + }, + { + "name": "vendor-routing-protocol", + "revision": "1.2.1", + } + ] + }, + { + "name": "vendor-schema", + "version": "1.4.5", + "module": [ + { + "name": "vendor-interfaces", + "revision": "1.0.0", + }, + { + "name": "vendor-routing-protocol", + "revision": "1.2.1", + } + ] + }, + } + ] +} + +This example + + + + + + vendor-schema + 2.1.0 + + vendor-interfaces + 3.0.0 + + + vendor-routing-protocol + 1.3.1 + + + + vendor-schema + 1.4.5 + + vendor-interfaces + 2.0.0 + + + vendor-routing-protocol + 1.2.1 + + + + + vendor-schema@2.1.0 + + vendor-schema@2.1.0 + + running + + vendor-schema + 2.1.0 + + + + operational + + vendor-schema + 2.1.0 + + + + + + vendor-schema@1.4.5 + + running + + vendor-schema + 1.4.5 + + + + operational + + vendor-schema + 1.4.5 + + + + + + diff --git a/yang-pkgs/tmp/ietf-datastores.yang b/common-dependencies/ietf-datastores.yang similarity index 100% rename from yang-pkgs/tmp/ietf-datastores.yang rename to common-dependencies/ietf-datastores.yang diff --git a/common-dependencies/ietf-inet-types@2019-07-21.yang b/common-dependencies/ietf-inet-types@2019-07-21.yang new file mode 100644 index 0000000..140de9c --- /dev/null +++ b/common-dependencies/ietf-inet-types@2019-07-21.yang @@ -0,0 +1,584 @@ +module ietf-inet-types { + + namespace "urn:ietf:params:xml:ns:yang:ietf-inet-types"; + prefix "inet"; + + organization + "IETF Network Modeling (NETMOD) Working Group"; + + contact + "WG Web: + WG List: + + Editor: Juergen Schoenwaelder + "; + + description + "This module contains a collection of generally useful derived + YANG data types for Internet addresses and related things. + + The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL + NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', + 'MAY', and 'OPTIONAL' in this document are to be interpreted as + described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, + they appear in all capitals, as shown here. + + Copyright (c) 2019 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 XXXX; + see the RFC itself for full legal notices."; + + revision 2019-07-21 { + description + "This revision adds the following new data types: + - ip-address-and-prefix + - ipv4-address-and-prefix + - ipv6-address-and-prefix + - email-address"; + reference + "RFC XXXX: Common YANG Data Types"; + } + + 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 . + + 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 prefix. + The prefix length is given by the number following the + slash character and must be less than or equal to 32. + + A prefix length value of n corresponds to an IP address + mask that has n contiguous 1-bits from the most + significant bit (MSB) and all other bits set to 0. + The canonical format of an IPv4 prefix has all bits of + the IPv4 address set to zero that are not part of the + IPv4 prefix. + + The definition of ipv4-prefix does not require that bits, + which are not part of the prefix, are set to zero. However, + implementations have to return values in canonical format, + which requires non-prefix bits to be set to zero. This means + that 192.0.2.1/24 must be accepted as a valid value but it + will be converted into the canonical format 192.0.2.0/24."; + } + + typedef ipv6-prefix { + type string { + pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' + + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' + + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' + + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' + + '(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))'; + pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' + + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' + + '(/.+)'; + } + description + "The ipv6-prefix type represents an IPv6 prefix. + The prefix length is given by the number following the + slash character and must be less than or equal to 128. + + A prefix length value of n corresponds to an IP address + mask that has n contiguous 1-bits from the most + significant bit (MSB) and all other bits set to 0. + + The canonical format of an IPv6 prefix has all bits of + the IPv6 address set to zero that are not part of the + IPv6 prefix. Furthermore, the IPv6 address is represented + as defined in Section 4 of RFC 5952. + + The definition of ipv6-prefix does not require that bits, + which are not part of the prefix, are set to zero. However, + implementations have to return values in canonical format, + which requires non-prefix bits to be set to zero. This means + that 2001:db8::1/64 must be accepted as a valid value but it + will be converted into the canonical format 2001:db8::/64."; + reference + "RFC 5952: A Recommendation for IPv6 Address Text + Representation"; + } + + typedef ip-address-and-prefix { + type union { + type inet:ipv4-address-and-prefix; + type inet:ipv6-address-and-prefix; + } + description + "The ip-address-and-prefix type represents an IP address and + prefix and is IP version neutral. The format of the textual + representations implies the IP version."; + } + + typedef ipv4-address-and-prefix { + type string { + pattern + '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' + + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])' + + '/(([0-9])|([1-2][0-9])|(3[0-2]))'; + } + description + "The ipv4-address-and-prefix type represents an IPv4 + address and an associated ipv4 prefix. + The prefix length is given by the number following the + slash character and must be less than or equal to 32. + + A prefix length value of n corresponds to an IP address + mask that has n contiguous 1-bits from the most + significant bit (MSB) and all other bits set to 0."; + } + + typedef ipv6-address-and-prefix { + type string { + pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' + + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' + + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' + + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' + + '(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))'; + pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' + + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' + + '(/.+)'; + } + description + "The ipv6-address-and-prefix type represents an IPv6 + address and an associated ipv4 prefix. + The prefix length is given by the number following the + slash character and must be less than or equal to 128. + + A prefix length value of n corresponds to an IP address + mask that has n contiguous 1-bits from the most + significant bit (MSB) and all other bits set to 0. + + The canonical format requires that the IPv6 address is + represented as defined in Section 4 of RFC 5952."; + reference + "RFC 5952: A Recommendation for IPv6 Address Text + Representation"; + } + + /*** collection of domain name and URI types ***/ + + typedef domain-name { + type string { + length "1..253"; + pattern + '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*' + + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)' + + '|\.'; + } + description + "The domain-name type represents a DNS domain name. The + name SHOULD be fully qualified whenever possible. + + 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 node instances 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"; + } + + /* + * DISCUSS: + * - Lada suggested to have a type that supports wildcards and + * the forward slash character. + */ + + 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."; + } + + /* + * DISCUSS: + * - Lada suggested to replace the inet:domain-name usage in + * the union with a new host-name definition that follows + * the NR-LDH definition in RFC 5890. + */ + + 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)"; + } + + typedef email-address { + type string { + // dot-atom-text "@" ... + pattern '[a-zA-Z0-9!#$%&'+"'"+'*+/=?^_`{|}~-]+' + + '(\.[a-zA-Z0-9!#$%&'+"'"+'*+/=?^_`{|}~-]+)*' + + '@' + + '[a-zA-Z0-9!#$%&'+"'"+'*+/=?^_`{|}~-]+' + + '(\.[a-zA-Z0-9!#$%&'+"'"+'*+/=?^_`{|}~-]+)*'; + } + description + "The email-address type represents an email address as + defined as addr-spec in RFC 5322 section 3.4.1."; + reference + "RFC 5322: Internet Message Format"; + } + + /* + * DISCUSS: + * - It was suggested to add email types following RFC 5322 + * email-address (addr-spec, per Section 3.4.1) + * named-email-address (name-addr, per Section 3.4) + * - This sounds useful but the devil is in the details, + * in particular name-addr is a quite complex construct; + * perhaps addr-spec is sufficient, this is also the + * format allowed in mailto: URIs (mailto: seems to use + * only a subset of addr-spec which may be good enough + * here as well). + * - Need to define a pattern that has a meaningful trade-off + * between precision and complexity (there are very tight + * pattern that are very long and complex). The current + * pattern does not take care of quoted-string, obs-local-part, + * domain-literal, obs-domain. + */ +} diff --git a/yang-pkgs/tmp/ietf-module-tags@2018-10-17.yang b/common-dependencies/ietf-module-tags@2018-10-17.yang similarity index 100% rename from yang-pkgs/tmp/ietf-module-tags@2018-10-17.yang rename to common-dependencies/ietf-module-tags@2018-10-17.yang diff --git a/yang-pkgs/tmp/ietf-origin.yang b/common-dependencies/ietf-origin.yang similarity index 100% rename from yang-pkgs/tmp/ietf-origin.yang rename to common-dependencies/ietf-origin.yang diff --git a/yang-pkgs/tmp/ietf-yang-instance-data@2019-07-04.yang b/common-dependencies/ietf-yang-instance-data@2019-07-04.yang similarity index 100% rename from yang-pkgs/tmp/ietf-yang-instance-data@2019-07-04.yang rename to common-dependencies/ietf-yang-instance-data@2019-07-04.yang diff --git a/yang-mod-ver/ietf-yang-library.yang b/common-dependencies/ietf-yang-library.yang similarity index 100% rename from yang-mod-ver/ietf-yang-library.yang rename to common-dependencies/ietf-yang-library.yang diff --git a/yang-pkgs/tmp/ietf-yang-structure-ext@2019-03-07.yang b/common-dependencies/ietf-yang-structure-ext@2019-03-07.yang similarity index 100% rename from yang-pkgs/tmp/ietf-yang-structure-ext@2019-03-07.yang rename to common-dependencies/ietf-yang-structure-ext@2019-03-07.yang diff --git a/yang-mod-ver/ietf-yang-types@2019-07-21.yang b/common-dependencies/ietf-yang-types@2019-07-21.yang similarity index 100% rename from yang-mod-ver/ietf-yang-types@2019-07-21.yang rename to common-dependencies/ietf-yang-types@2019-07-21.yang diff --git a/yang-mod-ver/draft-verdt-netmod-yang-module-versioning.xml b/yang-mod-ver/draft-verdt-netmod-yang-module-versioning.xml index 8467aa9..7b56e60 100644 --- a/yang-mod-ver/draft-verdt-netmod-yang-module-versioning.xml +++ b/yang-mod-ver/draft-verdt-netmod-yang-module-versioning.xml @@ -21,7 +21,7 @@ - + Updated YANG Module Revision Handling diff --git a/yang-mod-ver/ietf-yang-revisions.yang b/yang-mod-ver/ietf-yang-revisions.yang index 07612e2..1dd592f 100644 --- a/yang-mod-ver/ietf-yang-revisions.yang +++ b/yang-mod-ver/ietf-yang-revisions.yang @@ -92,6 +92,20 @@ module ietf-yang-revisions { Section 3.3, Revision label"; } + typedef name-revision { + type string { + length "1..512"; + pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*(@[^\s@]+)?'; + pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*'; + } + description + "Identifies a particular revision of a YANG asset (e.g. module + or package). + + Takes the form '' or '@', where + could be either a revision-date or a revision label."; + } + typedef revision-date-or-label { type union { type yang:revision-identifier; diff --git a/yang-pkgs/ietf-yang-types@2019-07-21.yang b/yang-pkgs/ietf-yang-types@2019-07-21.yang deleted file mode 100644 index 3d5db3e..0000000 --- a/yang-pkgs/ietf-yang-types@2019-07-21.yang +++ /dev/null @@ -1,717 +0,0 @@ -module ietf-yang-types { - - namespace "urn:ietf:params:xml:ns:yang:ietf-yang-types"; - prefix "yang"; - - organization - "IETF Network Modeling (NETMOD) Working Group"; - - contact - "WG Web: - WG List: - - Editor: Juergen Schoenwaelder - "; - - description - "This module contains a collection of generally useful derived - YANG data types. - - The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL - NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', - 'MAY', and 'OPTIONAL' in this document are to be interpreted as - described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, - they appear in all capitals, as shown here. - - Copyright (c) 2019 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 XXXX; - see the RFC itself for full legal notices."; - - revision 2019-07-21 { - description - "This revision adds the following new data types: - - date, time - - hours, minutes, seconds - - centiseconds, milliseconds, microseconds, nanoseconds - - revision-identifier, node-instance-identifier"; - reference - "RFC XXXX: Common YANG Data Types"; - } - - 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 instantiation of - a schema node of type counter32 at times other than - re-initialization, then a corresponding schema node - should be defined, with an appropriate type, to indicate - the last discontinuity. - The counter32 type should not be used for configuration - schema nodes. A default statement SHOULD NOT be used in - combination with the type counter32. - - In the value set and its semantics, this type is equivalent - to the Counter32 type of the SMIv2."; - reference - "RFC 2578: Structure of Management Information Version 2 - (SMIv2)"; - } - - typedef zero-based-counter32 { - type yang: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) - 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 - actual time between polls, and to discard data if the actual - time is too long or there is no defined minimum time. - - In the value set and its semantics, this type is equivalent - to the ZeroBasedCounter32 textual convention of the SMIv2."; - reference - "RFC 4502: Remote Network Monitoring Management Information - Base Version 2"; - } - - typedef counter64 { - type uint64; - description - "The counter64 type represents a non-negative integer - that monotonically increases until it reaches a - maximum value of 2^64-1 (18446744073709551615 decimal), - when it wraps around and starts increasing again from zero. - - Counters have no defined 'initial' value, and thus, a - single value of a counter has (in general) no information - content. Discontinuities in the monotonically increasing - value normally occur at re-initialization of the - management system, and at other times as specified in the - description of a schema node using this type. If such - other times can occur, for example, the instantiation of - a schema node of type counter64 at times other than - re-initialization, then a corresponding schema node - should be defined, with an appropriate type, to indicate - the last discontinuity. - - The counter64 type should not be used for configuration - schema nodes. A default statement SHOULD NOT be used in - combination with the type counter64. - - In the value set and its semantics, this type is equivalent - to the Counter64 type of the SMIv2."; - reference - "RFC 2578: Structure of Management Information Version 2 - (SMIv2)"; - } - - typedef zero-based-counter64 { - type yang: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) - 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 - 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)"; - } - - /*** 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 date-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 date { - type string { - pattern '\d{4}-\d{2}-\d{2}' - + '(Z|[\+\-]\d{2}:\d{2})'; - } - description - "The date type represents a time-interval of the length - of a day, i.e., 24 hours. - - The date type is compatible with the date XML schema - type with the following notable exceptions: - - (a) The date type does not allow negative years. - - (b) The date 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 date. - - (c) The canonical format (see below) of data values - differs from the canonical format used by the date XML - schema type, which requires all times to be in UTC using - the time-offset 'Z'. - - The canonical format for date values with a known time - zone uses a numeric time zone offset that is calculated using - the device's configured known offset to UTC time. A change of - the device's offset to UTC time will cause date values - to change accordingly. Such changes might happen periodically - in case a server follows automatically daylight saving time - (DST) time zone offset changes. The canonical format for - date values 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 - XSD-TYPES: XML Schema Part 2: Datatypes Second Edition"; - } - - /* - * DISCUSS: - * - XML schema seems to use a different canonical format, we - * need to take a closer look how to define the canonical format - * given that a data really identifies a 24 hour interval and - * what XSD means with 'interval midpoint'. - */ - - typedef time { - type string { - pattern '\d{2}:\d{2}:\d{2}(\.\d+)?' - + '(Z|[\+\-]\d{2}:\d{2})'; - } - description - "The time type represents an instance of time of zero-duration - that recurs every day. - - The time type is compatible with the time XML schema - type with the following notable exceptions: - - (a) The 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 time. - - (c) The canonical format (see below) of time values - differs from the canonical format used by the time XML - schema type, which requires all times to be in UTC using - the time-offset 'Z'. - - The canonical format for time values with a known time - zone uses a numeric time zone offset that is calculated using - the device's configured known offset to UTC time. A change of - the device's offset to UTC time will cause time values - to change accordingly. Such changes might happen periodically - in case a server follows automatically daylight saving time - (DST) time zone offset changes. The canonical format for - time values 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 - XSD-TYPES: XML Schema Part 2: Datatypes Second Edition"; - } - - typedef hours { - type uint32; - units "hours"; - description - "A period of time, measured in units of hours."; - } - - typedef minutes { - type uint32; - units "minutes"; - description - "A period of time, measured in units of minutes."; - } - - typedef seconds { - type uint32; - units "seconds"; - description - "A period of time, measured in units of seconds. - The maximum duration that can be expressed is in the - order of 49710 days and 6 hours and 28 minutes and 15 - seconds."; - } - - typedef centiseconds { - type uint32; - units "centiseconds"; - description - "A period of time, measured in units of 10^-2 seconds. - The maximum duration that can be expressed is in the - order of 497 days and 2 hours and 27 minutes and 52 - seconds."; - } - - typedef milliseconds { - type uint32; - units "milliseconds"; - description - "A period of time, measured in units of 10^-3 seconds. - The maximum duration that can be expressed is in the - order of 49 days and 17 hours and 2 minutes and 47 - seconds."; - } - - typedef microseconds { - type uint32; - units "microseconds"; - description - "A period of time, measured in units of 10^-6 seconds. - The maximum duration that can be expressed is in the - order of 1 hour and 11 minutes and 34 seconds."; - } - - typedef nanoseconds { - type uint32; - units "nanoseconds"; - description - "A period of time, measured in units of 10^-9 seconds. - The maximum duration that can be expressed is in the - order of 4 seconds."; - } - - /* - * DISCUSS: - * - do we need (nano|micro|milli)seconds with 64 bits? - * - do we add typedef timeinterval { type centiseconds - * { range 0..2147483647 } } for compatibility with SMIv2? - * - some modules use negative minutes, do we care? A _duration_ - * does likely not need negative values. However, if minutes are - * used to represent a relative time offset, then negative minutes - * do make sense. Do we have to support durations as well as - * time offsets? - */ - - 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 instance at which a specific occurrence - happened. The specific occurrence must be defined in the - description of any schema node defined using this type. When - the specific occurrence occurred prior to the last time the - associated timeticks schema node instance was zero, then the - timestamp value is zero. - - Note that this requires all timestamp values to be reset to - zero when the value of the associated timeticks schema node - instance reaches 497+ days and wraps around to zero. - - The associated timeticks schema node must be specified - in the description of any schema node using this type. - - In the value set and its semantics, this type is equivalent - to the TimeStamp textual convention of the SMIv2."; - reference - "RFC 2579: Textual Conventions for SMIv2"; - } - - /*** collection of generic address types ***/ - - typedef phys-address { - type string { - pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?'; - } - description - "Represents media- or physical-level addresses represented - as a sequence octets, each octet represented by two hexadecimal - numbers. Octets are separated by colons. The canonical - representation uses lowercase characters. - - In the value set and its semantics, this type is equivalent - to the PhysAddress textual convention of the SMIv2."; - reference - "RFC 2579: Textual Conventions for SMIv2"; - } - - typedef mac-address { - type string { - pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}'; - } - description - "The mac-address type represents 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"; - } - - /* - * DISCUSS: - * - How do we deal with xpath expressions in other encodings - * such as JSON. Do we assume an xpath context populated with - * module names such that module names can be used to qualify - * path expressions. This may need discussion and/or a new - * definition. - * - This interacts with the definition of node-instance-identifier. - */ - - /*** 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."; - } - - /*** collection of YANG specific types ***/ - - 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)"; - } - - typedef revision-identifier { - type date { - pattern '\d{4}-\d{2}-\d{2}'; - } - description - "Represents a specific revision of a YANG module by means of - a date value without a time zone."; - } - - typedef node-instance-identifier { - type xpath1.0; - description - "Path expression used to represent a special - data node, action, or notification instance-identifier - string. - - A node-instance-identifier value is an - unrestricted YANG instance-identifier expression. - - All the same rules as an instance-identifier apply, - except that predicates for keys are optional. If a key - predicate is missing, then the node-instance-identifier - represents all possible server instances for that key. - - This XML Path Language (XPath) expression is evaluated in the - following context: - - o The set of namespace declarations are those in scope on - the leaf element where this type is used. - - o The set of variable bindings contains one variable, - 'USER', which contains the name of the user of the - current session. - - o The function library is the core function library, but - note that due to the syntax restrictions of an - instance-identifier, no functions are allowed. - - o The context node is the root node in the data tree. - - The accessible tree includes actions and notifications tied - to data nodes."; - } - - /* - * DISCUSS: - * - This is taken from RFC 8341 and the idea is that this definition - * is useful without requiring a dependency on NACM - * - What does the second bullet actually do? Do we keep this? - * - How does this work with JSON? Can we make this encoding neutral - * (but then we knowingly depart from NACM)? - * - This interacts with the definition of xpath1.0. - */ - - /* DISCUSS: - * - It was suggested to add types for longitude, latitude, - * postal code, country-code. Do we go there or do we leave - * these for other modules to define? It seems such definitions - * should go into draft-ietf-netmod-geo-location. - */ - - /* DISCUSS: - * - It was suggested to add percentage types but they tend to differ - * widely. However, percentages are also widely used. - */ -} diff --git a/yang-pkgs/tmp/ietf-yang-library.yang b/yang-pkgs/tmp/ietf-yang-library.yang deleted file mode 100644 index 5d0a2ff..0000000 --- a/yang-pkgs/tmp/ietf-yang-library.yang +++ /dev/null @@ -1,568 +0,0 @@ -module ietf-yang-library { - yang-version 1.1; - namespace "urn:ietf:params:xml:ns:yang:ietf-yang-library"; - prefix "yanglib"; - - import ietf-yang-types { - prefix yang; - reference "RFC 6991: Common YANG Data Types."; - } - import ietf-inet-types { - prefix inet; - reference "RFC 6991: Common YANG Data Types."; - } - import ietf-datastores { - prefix ds; - reference "RFC 8342: Network Management Datastore Architecture."; - } - - organization - "IETF NETCONF (Network Configuration) Working Group"; - - contact - "WG Web: - WG List: - - Author: Andy Bierman - - - Author: Martin Bjorklund - - - Author: Juergen Schoenwaelder - - - Author: Kent Watsen - - - Author: Rob Wilton - "; - - description - "This module provides information about the YANG modules, - datastores, and datastore schemas used by a network - management server. - - Copyright (c) 2018 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 XXXX; see - the RFC itself for full legal notices."; - - // RFC Ed.: update the date below with the date of RFC publication - // and remove this note. - // RFC Ed.: replace XXXX with actual RFC number and remove this - // note. - revision 2018-10-16 { - description - "Added support for multiple datastores according to the - Network Management Datastore Architecture (NMDA)."; - reference - "RFC XXXX: YANG Library."; - } - revision 2016-04-09 { - description - "Initial revision."; - reference - "RFC 7895: YANG Module Library."; - } - - /* - * Typedefs - */ - - typedef revision-identifier { - type string { - pattern '\d{4}-\d{2}-\d{2}'; - } - description - "Represents a specific date in YYYY-MM-DD format."; - } - - /* - * Groupings - */ - - grouping module-identification-leafs { - description - "Parameters for identifying YANG modules and submodules."; - - leaf name { - type yang:yang-identifier; - mandatory true; - description - "The YANG module or submodule name."; - } - leaf revision { - type revision-identifier; - description - "The YANG module or submodule revision date. If no revision - statement is present in the YANG module or submodule, this - leaf is not instantiated."; - } - } - - grouping location-leaf-list { - description - "Common location leaf list parameter for modules and - submodules."; - - leaf-list location { - type inet:uri; - description - "Contains a URL that represents the YANG schema - resource for this module or submodule. - - This leaf will only be present if there is a URL - available for retrieval of the schema for this entry."; - } - } - - grouping module-implementation-parameters { - description - "Parameters for describing the implementation of a module."; - - leaf-list feature { - type yang:yang-identifier; - description - "List of all YANG feature names from this module that are - supported by the server, regardless whether they are defined - in the module or any included submodule."; - } - leaf-list deviation { - type leafref { - path "../../module/name"; - } - description - "List of all YANG deviation modules used by this server to - modify the conformance of the module associated with this - entry. Note that the same module can be used for deviations - for multiple modules, so the same entry MAY appear within - multiple 'module' entries. - - This reference MUST NOT (directly or indirectly) - refer to the module being deviated. - - Robust clients may want to make sure that they handle a - situation where a module deviates itself (directly or - indirectly) gracefully."; - } - } - - grouping module-set-parameters { - description - "A set of parameters that describe a module set."; - - leaf name { - type string; - description - "An arbitrary name of the module set."; - } - list module { - key "name"; - description - "An entry in this list represents a module implemented by the - server, as per RFC 7950 section 5.6.5, with a particular set - of supported features and deviations."; - reference - "RFC 7950: The YANG 1.1 Data Modeling Language."; - - uses module-identification-leafs; - - leaf namespace { - type inet:uri; - mandatory true; - description - "The XML namespace identifier for this module."; - } - - uses location-leaf-list; - - list submodule { - key "name"; - description - "Each entry represents one submodule within the - parent module."; - uses module-identification-leafs; - uses location-leaf-list; - } - - uses module-implementation-parameters; - } - list import-only-module { - key "name revision"; - description - "An entry in this list indicates that the server imports - reusable definitions from the specified revision of the - module, but does not implement any protocol accessible - objects from this revision. - - Multiple entries for the same module name MAY exist. This - can occur if multiple modules import the same module, but - specify different revision-dates in the import statements."; - - leaf name { - type yang:yang-identifier; - description - "The YANG module name."; - } - leaf revision { - type union { - type revision-identifier; - type string { - length 0; - } - } - description - "The YANG module revision date. - A zero-length string is used if no revision statement - is present in the YANG module."; - } - leaf namespace { - type inet:uri; - mandatory true; - description - "The XML namespace identifier for this module."; - } - - uses location-leaf-list; - - list submodule { - key "name"; - description - "Each entry represents one submodule within the - parent module."; - - uses module-identification-leafs; - uses location-leaf-list; - } - } - } - - grouping yang-library-parameters { - description - "The YANG library data structure is represented as a grouping - so it can be reused in configuration or another monitoring - data structure."; - - list module-set { - key name; - description - "A set of modules that may be used by one or more schemas. - - A module set does not have to be referentially complete, - i.e., it may define modules that contain import statements - for other modules not included in the module set."; - - uses module-set-parameters; - } - - list schema { - key "name"; - description - "A datastore schema that may be used by one or more - datastores. - - The schema must be valid and referentially complete, i.e., - it must contain modules to satisfy all used import - statements for all modules specified in the schema."; - - leaf name { - type string; - description - "An arbitrary name of the schema."; - } - leaf-list module-set { - type leafref { - path "../../module-set/name"; - } - description - "A set of module-sets that are included in this schema. - If a non import-only module appears in multiple module - sets, then the module revision and the associated features - and deviations must be identical."; - } - } - - list datastore { - key "name"; - description - "A datastore supported by this server. - - Each datastore indicates which schema it supports. - - The server MUST instantiate one entry in this list per - specific datastore it supports. - - Each datstore entry with the same datastore schema SHOULD - reference the same schema."; - - leaf name { - type ds:datastore-ref; - description - "The identity of the datastore."; - } - leaf schema { - type leafref { - path "../../schema/name"; - } - mandatory true; - description - "A reference to the schema supported by this datastore. - All non import-only modules of the schema are implemented - with their associated features and deviations."; - } - } - } - - /* - * Top-level container - */ - - container yang-library { - config false; - description - "Container holding the entire YANG library of this server."; - - uses yang-library-parameters; - - leaf content-id { - type string; - mandatory true; - description - "A server-generated identifier of the contents of the - 'yang-library' tree. The server MUST change the value of - this leaf if the information represented by the - 'yang-library' tree, except 'yang-library/content-id', has - changed."; - } - } - - /* - * Notifications - */ - - notification yang-library-update { - description - "Generated when any YANG library information on the - server has changed."; - - leaf content-id { - type leafref { - path "/yanglib:yang-library/yanglib:content-id"; - } - mandatory true; - description - "Contains the YANG library content identifier for the updated - YANG library at the time the notification is generated."; - } - } - - /* - * Legacy groupings - */ - - grouping module-list { - status deprecated; - description - "The module data structure is represented as a grouping - so it can be reused in configuration or another monitoring - data structure."; - - grouping common-leafs { - status deprecated; - description - "Common parameters for YANG modules and submodules."; - - leaf name { - type yang:yang-identifier; - status deprecated; - description - "The YANG module or submodule name."; - } - leaf revision { - type union { - type revision-identifier; - type string { - length 0; - } - } - status deprecated; - description - "The YANG module or submodule revision date. - A zero-length string is used if no revision statement - is present in the YANG module or submodule."; - } - } - grouping schema-leaf { - status deprecated; - description - "Common schema leaf parameter for modules and submodules."; - leaf schema { - type inet:uri; - description - "Contains a URL that represents the YANG schema - resource for this module or submodule. - - This leaf will only be present if there is a URL - available for retrieval of the schema for this entry."; - } - } - - list module { - key "name revision"; - status deprecated; - description - "Each entry represents one revision of one module - currently supported by the server."; - - uses common-leafs { - status deprecated; - } - uses schema-leaf { - status deprecated; - } - - leaf namespace { - type inet:uri; - mandatory true; - status deprecated; - description - "The XML namespace identifier for this module."; - } - leaf-list feature { - type yang:yang-identifier; - status deprecated; - description - "List of YANG feature names from this module that are - supported by the server, regardless whether they are - defined in the module or any included submodule."; - } - list deviation { - key "name revision"; - status deprecated; - description - "List of YANG deviation module names and revisions - used by this server to modify the conformance of - the module associated with this entry. Note that - the same module can be used for deviations for - multiple modules, so the same entry MAY appear - within multiple 'module' entries. - - The deviation module MUST be present in the 'module' - list, with the same name and revision values. - The 'conformance-type' value will be 'implement' for - the deviation module."; - uses common-leafs { - status deprecated; - } - } - leaf conformance-type { - type enumeration { - enum implement { - description - "Indicates that the server implements one or more - protocol-accessible objects defined in the YANG module - identified in this entry. This includes deviation - statements defined in the module. - - For YANG version 1.1 modules, there is at most one - module entry with conformance type 'implement' for a - particular module name, since YANG 1.1 requires that - at most one revision of a module is implemented. - - For YANG version 1 modules, there SHOULD NOT be more - than one module entry for a particular module name."; - } - enum import { - description - "Indicates that the server imports reusable definitions - from the specified revision of the module, but does - not implement any protocol accessible objects from - this revision. - - Multiple module entries for the same module name MAY - exist. This can occur if multiple modules import the - same module, but specify different revision-dates in - the import statements."; - } - } - mandatory true; - status deprecated; - description - "Indicates the type of conformance the server is claiming - for the YANG module identified by this entry."; - } - list submodule { - key "name revision"; - status deprecated; - description - "Each entry represents one submodule within the - parent module."; - uses common-leafs { - status deprecated; - } - uses schema-leaf { - status deprecated; - } - } - } - } - - /* - * Legacy operational state data nodes - */ - - container modules-state { - config false; - status deprecated; - description - "Contains YANG module monitoring information."; - - leaf module-set-id { - type string; - mandatory true; - status deprecated; - description - "Contains a server-specific identifier representing - the current set of modules and submodules. The - server MUST change the value of this leaf if the - information represented by the 'module' list instances - has changed."; - } - - uses module-list { - status deprecated; - } - } - - /* - * Legacy notifications - */ - - notification yang-library-change { - status deprecated; - description - "Generated when the set of modules and submodules supported - by the server has changed."; - leaf module-set-id { - type leafref { - path "/yanglib:modules-state/yanglib:module-set-id"; - } - mandatory true; - status deprecated; - description - "Contains the module-set-id value representing the - set of modules and submodules supported at the server - at the time the notification is generated."; - } - } - -} diff --git a/yang-pkgs/tmp/ietf-yang-revisions.yang b/yang-pkgs/tmp/ietf-yang-revisions.yang deleted file mode 100644 index 1dd592f..0000000 --- a/yang-pkgs/tmp/ietf-yang-revisions.yang +++ /dev/null @@ -1,218 +0,0 @@ -module ietf-yang-revisions { - yang-version 1.1; - namespace "urn:ietf:params:xml:ns:yang:ietf-yang-revisions"; - prefix rev; - - import ietf-yang-types { - prefix yang; - reference - "XXXX [ietf-netmod-rfc6991-bis]: Common YANG Data Types"; - } - - organization - "IETF NETMOD (Network Modeling) Working Group"; - contact - "WG Web: - WG List: - - Author: Benoit Claise - - - Author: Joe Clarke - - - Author: Reshad Rahman - - - Author: Robert Wilton - - - Author: Kevin D'Souza - - - Author: Balazs Lengyel - - - Author: Jason Sterne - "; - description - "This YANG 1.1 module contains definitions and extensions to - support updated YANG revision handling. - - Copyright (c) 2019 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 XXXX; see - the RFC itself for full legal notices. - - 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."; - - // RFC Ed.: update the date below with the date of RFC publication - // and remove this note. - // RFC Ed.: replace XXXX (inc above) with actual RFC number and - // remove this note. - - revision 2019-09-18 { - description - "Initial version."; - reference - "XXXX: Updated YANG Module Revision Handling"; - } - - typedef revision-label { - type string { - length "1..255"; - pattern '[^\s@]+'; - pattern '\d{4}-\d{2}-\d{2}' { - modifier invert-match; - } - } - description - "A label associated with a YANG revision. - - Excludes spaces and '@'. MUST NOT match revision-date. - - Revision labels that classify as YANG semantic versions, - as defined by the ietf-yang-semver:version typedef, - MUST conform to the versioning behaviour defined in - XXXX [verdt]: YANG Semantic Versioning."; - reference - "XXXX: Updated YANG Module Revision Handling; - Section 3.3, Revision label"; - } - - typedef name-revision { - type string { - length "1..512"; - pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*(@[^\s@]+)?'; - pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*'; - } - description - "Identifies a particular revision of a YANG asset (e.g. module - or package). - - Takes the form '' or '@', where - could be either a revision-date or a revision label."; - } - - typedef revision-date-or-label { - type union { - type yang:revision-identifier; - type revision-label; - } - description - "Represents either a YANG revision date or a revision label"; - } - - extension nbc-changes { - description - "This statement is used to indicate YANG module revisions that - contain non-backwards-compatible changes. - - Each 'revision' statement MAY have a single 'nbc-changes' - substatement. - - If a revision of a YANG module contains changes, relative to - the preceding revision in the revision history, that do not - conform to the module update rules defined in RFC-XXX, then - the 'nbc-changes' statement MUST be added as a substatement to - the revision statement. - - Conversely, if a revision of a YANG module only contains - changes, relative to the preceding revision in the revision - history, that are classified as 'backwards-compatible' then - the revision statement MUST NOT contain any 'nbc-changes' - substatement."; - - reference - "XXXX: Updated YANG Module Revision Handling; - Section 3.2, nbc-changes revision extension statement"; - } - - extension revision-label { - argument revision-label; - description - "The revision label can be used to provide an additional - versioning identifier associated with the revision. E.g., one - option for a versioning scheme that could be used is [TODO - - Reference semver draft]. - - The format of the revision-label argument MUST conform to the - pattern defined for the revision-label typedef. - - Each 'revision' statement MAY have a single 'revision-label' - substatement. - - Revision labels MUST be unique amongst all revisions of a - module."; - - reference - "XXXX: Updated YANG Module Revision Handling; - Section 3.3, Revision label"; - } - - extension revision-or-derived { - argument revision-date-or-label; - description - "Restricts the revision of the module that may be imported to - one that matches or is derived from the specified - revision-date or revision-ñlabel. - - The argument value MUST conform to the - 'revision-date-or-label' defined type. - - Each 'import' statement MAY have one or more - 'revision-or-derived' substatements. If specified multiple - times, then any module revision that satifies at least one of - the 'revision-or-derived' statements is an acceptable revision - for import. - - An 'import' statement MUST NOT contain both a - 'revision-or-derived' extension statement and a - 'revision-date' statement. - - A particular revision of an imported module satisfies an - import's 'revision-or-derived' extension statement if the - imported module's revision history contains a revision - statement with a matching revision date or revision label. - - The 'revision-or-derived' extension statement does not - gaurantee that all module revisions that satisfy an import - statement are necessarily compatible, it only gives an - indication that the revisions are more likely to be - compatible."; - - reference - "XXXX: Updated YANG Module Revision Handling; - Section 4, Import by derived revision"; - } - - extension status-description { - argument description; - - description - "Freeform text that describes why a given node has been - deprecated or made obsolete. E.g., the description could be - used to give the reason for removal, or it could point to an - alternative schema elements that can be used in lieu of the - given node. - - Each 'status' statement MAY have a single 'status-description' - substatement."; - - reference - "XXXX: Updated YANG Module Revision Handling; - Section 3.4, YANG status description extension statement"; - } -} diff --git a/yang-ver-selection/ietf-schema-selection.yang b/yang-ver-selection/ietf-schema-selection.yang new file mode 100644 index 0000000..a3cf45c --- /dev/null +++ b/yang-ver-selection/ietf-schema-selection.yang @@ -0,0 +1,356 @@ +module ietf-schema-selection { + yang-version 1.1; + namespace + "urn:ietf:params:xml:ns:yang:ietf-schema-selection"; + prefix "schsel"; + + import ietf-yang-revisions { + prefix rev; + reference "XXXX: Updated YANG Module Revision Handling"; + } + + import ietf-datastores { + prefix ds; + rev:revision-or-derived 2018-02-14; + reference + "RFC 8342: Network Management Datastore Architecture (NMDA)"; + } + + import ietf-yang-packages { + prefix pkgs; + rev:revision-or-derived 0.2.0; + reference "RFC XXX: YANG Packages."; + } + + + organization + "IETF NETMOD (Network Modeling) Working Group"; + + contact + "WG Web: + WG List: + + Author: Reshad Rahman + + + Author: Rob Wilton + "; + + description + "This module provide a data model to advertise and allow the + selection of schema versions by clients. + + Copyright (c) 2019 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 XXXX; see + the RFC itself for full legal notices. + + 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."; + + + // RFC Ed.: update the date below with the date of RFC publication + // and remove this note. + // RFC Ed.: replace XXXX with actual RFC number and remove this + // note. + revision 2019-11-29 { + description + "Initial revision"; + reference + "RFC XXXX: YANG Schema Version Selection"; + } + + /* + * Features + */ + feature "primary-schema-set" { + description + "Feature that allows clients to choose the primary schema set + to be used for clients (via RPC)"; + } + + feature "secondary-schema-set" { + description + "Feature to choose if secondary schema set may be configured by + clients."; + } + + feature "custom-schema-set" { + if-feature "primary-schema-set or secondary-schema-set"; + description + "Feature to choose whether clients may configurable custom + schema definitions."; + } + + /* + * Top level data nodes. + */ + + container schema-set-selection { + description + "YANG schema-set selection. + + Contains configuration and state related to client selectable + YANG schema-sets."; + + leaf primary { + type leafref { + path "/schema-set-selection/schema-set/name"; + } + config false; + description + "Defines the primary schema-set used by this server. + + This is the schema-set that is chosen if a NETCONF client + doesn't select a schema during capability negotiation, or if + the standard RESTCONF (or NMDA datastore URLs) are used. + + This schema also represents the datastore schema that is + used to persist configuration for all conventional + configuration datastores."; + } + + leaf-list secondary { + if-feature "secondary-schema-set"; + type leafref { + path "/schema-set-selection/schema-set/name"; + require-instance false; + } + description + "Specifies the secondary schema used by this server, that can + be selected by clients (either through NETCONF capability + negotiation or RESTCONF schema specific path)."; + } + + list custom { + if-feature "custom-schema-set"; + key "name"; + + description + "Defines a custom selectable schema constructed from + compatible schema"; + + leaf name { + type "string"; + description + "Name of custom schema. + + Format can either be the form of a YANG identifer, or + '@'. + + The selectable-schema name is used in NETCONF capabilties + negotiation and also the RESTCONF path (XXX, is encoding + required, e.g. for '@'?)"; + } + + leaf description { + type string; + description + "The description associated with this custom package."; + } + + leaf-list included-schema { + type leafref { + path "/schema-set-selection/schema-set/name"; + require-instance false; + } + description + "Lists the schema that are combined together into a single + selectable schema (i.e. via a union operation on each + datastore schema package)."; + } + } + + list schema-set { + key "name"; + config false; + + description + "Lists all available schema-set's that can be used in schema + version selection."; + + leaf name { + type string; + + description + "Name of the schema. + + Do we restrict what is allowed, specifically, do we allow + '@'"; + } + + list common-package { + key "name version"; + + description + "YANG packages associated with all datastores supported by + this schema-set. + + Packages are unioned together, along with any per + datastore packages, with no conflicts allowed."; + + uses pkgs:yang-pkg-ref; + } + + list datastore { + key "name"; + + description + "The list of datastores supported for this pan-datastore + selectable-package, along with the package schema + associated with that datastore."; + + leaf name { + type ds:datastore-ref; + description + "The datastore that this datastore schema is associated + with."; + reference + "RFC 8342: Network Management Datastore Architecture + (NMDA)"; + } + + leaf read-only { + type empty; + description + "Indicates that this schema-set cannot be written, even + for writable datastores. E.g., if was a + supported datastore then it could be read, but not + written."; + } + + list additional-package { + key "name version"; + + description + "YANG packages used in addition to the common-packages. + + The datastore schema is represented as the union of all + common-packages in the schema-set joined with any per + datastore packages."; + + uses pkgs:yang-pkg-ref; + } + } + + leaf primary-selectable { + if-feature "primary-schema-set"; + type empty; + description + "Indicates that this schema-set is selectable as a primary + schema-set."; + } + + container secondary-selectable { + if-feature "secondary-schema-set"; + presence + "This schema MAY be selected as a secondary schema-set"; + description + "Indicates that this schema-set is selectable as a + secondary schema-set and also defines compatibility with + primary and secondary schema-sets."; + + container compatible-with { + description + "Contains the compatible primary and secondary schema"; + + leaf-list primary { + type leafref { + path "/schema-set-selection/schema-set/name"; + } + description + "Lists other schema that MAY be selected as the default + schema at ths same time as this schema is selected as + a secondary-schema."; + } + + leaf-list secondary { + type leafref { + path "/schema-set-selection/schema-set/name"; + } + description + "Lists other schema that MAY be selected as other + secondary schema is this schema is selected as a + secondary-schema."; + } + } + } + + container custom-selectable { + if-feature "custom-schema-set"; + presence + "This schema MAY be selected as part of a custom + schema-set."; + description + "Indicates that this schema-set is selectable as part of a + custom schema-set and also lists other schema-sets that + may be combined together into a custom schema-set."; + + leaf-list combinable { + type leafref { + path "/schema-set-selection/schema-set/name"; + } + description + "Lists the schema-sets that MAY be combined with this + schema into a single custom schema-set'."; + } + } + } + } + + /* + * RPCs + */ + + rpc change-primary { + if-feature "primary-schema-set"; + description + "RPC to allow a client to change the primary schema-set used by + a server."; + + input { + leaf primary { + type leafref { + path "/schema-set-selection/schema-set/name"; + } + mandatory true; + description + "Changes the primary schema-set used by this server."; + } + choice config { + mandatory true; + description + "Specifies how the configuration is handled when the + primary schema is changed to the new schema-set."; + + leaf translate { + type empty; + description + "Translate the existing configuration to the new + schema-set, or fail the operation if this is not + possible."; + } + + anydata replacement-config { + description + "The configuration, in a form compatible with the new + schema-set, that is used to replace the existing + configuration, when it is changed to the new schema-set. + The operational MUST be failed if this new configuration + is not valid."; + } + } + } + } +} diff --git a/yang-ver-selection/tmp/ietf-module-tags@2018-10-17.yang b/yang-ver-selection/tmp/ietf-module-tags@2018-10-17.yang deleted file mode 100644 index ee3a4b9..0000000 --- a/yang-ver-selection/tmp/ietf-module-tags@2018-10-17.yang +++ /dev/null @@ -1,106 +0,0 @@ -module ietf-module-tags { - yang-version 1.1; - namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags"; - prefix tags; - - import ietf-yang-types { - prefix yang; - } - - organization - "IETF NetMod Working Group (NetMod)"; - contact - "NetMod Working Group - "; - - // RFC Ed.: replace XXXX with actual RFC number and - // remove this note. - - description - "This module describes a mechanism associating tags with YANG - modules. Tags may be IANA assigned or privately defined. - - Copyright (c) 2018 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 - (https://trustee.ietf.org/license-info). - - The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL - NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and - 'OPTIONAL' in the module text are to be interpreted as described - in RFC 2119 (https://tools.ietf.org/html/rfc2119). - - This version of this YANG module is part of RFC XXXX - (https://tools.ietf.org/html/rfcXXXX); see the RFC itself for - full legal notices."; - - // RFC Ed.: update the date below with the date of RFC publication - // and RFC number and remove this note. - - revision 2018-10-17 { - description - "Initial revision."; - reference "RFC XXXX: YANG Module Tags"; - } - - typedef tag { - type string { - length "1..max"; - pattern '[a-zA-Z_][a-zA-Z0-9\-_]*:[\S ]+'; - } - description - "A tag value is composed of a standard prefix followed by any type - 'string' value that does not include carriage return, newline or - tab characters."; - } - - extension module-tag { - argument tag; - description - "The argument 'tag' is of type 'tag'. This extension statement is - used by module authors to indicate the tags that SHOULD be added - automatically by the system. As such the origin of the value - for the pre-defined tags should be set to 'system'."; - } - - container module-tags { - description - "Contains the list of modules and their associated tags"; - list module { - key "name"; - description - "A list of modules and their associated tags"; - leaf name { - type yang:yang-identifier; - mandatory true; - description - "The YANG module name."; - } - leaf-list tag { - type tag; - description - "Tags associated with the module. See the IANA 'YANG Module - Tag Prefix' registry for reserved prefixes and the IANA 'YANG - Module IETF Tag' registry for IETF standard tags. - - The operational view of this list is constructed using the following steps: - - 1) System added tags are added. - 2) User configured tags are added. - 3) Any tag that is equal to a masked-tag is removed."; - } - leaf-list masked-tag { - type tag; - description - "The list of tags that should not be associated with this - module. This user can remove (mask) tags by adding - them to this list. It is not an error to add tags to this - list that are not associated with the module."; - } - } - } -} diff --git a/yang-ver-selection/tmp/ietf-schema-selection.yang b/yang-ver-selection/tmp/ietf-schema-selection.yang deleted file mode 100644 index 7a08c27..0000000 --- a/yang-ver-selection/tmp/ietf-schema-selection.yang +++ /dev/null @@ -1,314 +0,0 @@ -module ietf-schema-selection { - yang-version 1.1; - namespace - "urn:ietf:params:xml:ns:yang:ietf-schema-selection"; - prefix "ver-sel"; - - import ietf-datastores { - prefix ds; - reference - "RFC 8342: Network Management Datastore Architecture (NMDA)"; - } - - import ietf-yang-library { - prefix yanglib; - reference "RFC 8525: YANG Library"; - } - - import ietf-yl-packages { - prefix yl-pkg; - reference "RFC XXXX: YANG Packages"; - } - - organization - "IETF NETMOD (Network Modeling) Working Group"; - - contact - "WG Web: - WG List: - - Author: Reshad Rahman - - - Author: Rob Wilton - "; - - description - "This module provide a data model to advertise and allow the - selection of schema versions by clients. - - Copyright (c) 2019 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 XXXX; see - the RFC itself for full legal notices."; - - // RFC Ed.: update the date below with the date of RFC publication - // and remove this note. - // RFC Ed.: replace XXXX with actual RFC number and remove this - // note. - revision 2019-11-29 { - description - "Initial revision"; - reference - "RFC XXXX: YANG Schema Version Selection"; - } - - /* - * Features - */ - feature "default-schema" { - description - "Feature that allows clients to choose the default schema set - to be used for clients. - - Implementations may choose to only support this feature in - to report the default-schema-set without - allowing it to be configured."; - } - - feature "secondary-schema" { - description - "Feature to choose if secondary schema may be configured by - clients. - - Implementations may choose to only support this feature in - to report secondary schema sets without - allowing them to be configured."; - } - - feature "custom-schema" { - if-feature "default-schema or secondary-schema"; - description - "Feature to choose whether clients may configurable custom - schema definitions."; - } - - container schema-selection { - description - "YANG schema selection. - - Contains configuration and state related to client selectable - YANG schema versions."; - - leaf default-schema { - if-feature "default-schema"; - type leafref { - path "/schema-selection/schema/name"; - require-instance false; - } - description - "Specifies the default schema used by this device. - - This is the schema that is chosen if a NETCONF client doesn't - select a schema during capability negotiation, or if the - standard RESTCONF (or NMDA datastore URLs) are used. - - This schema also represents the datastore schema that is used - to persist configuration for all conventional configuration - datastores. - - If not configured, the operational state indicates the - default schema used by this device."; - } - - leaf-list secondary-schema { - if-feature "secondary-schema"; - type leafref { - path "/schema-selection/schema/name"; - require-instance false; - } - description - "Specifies the secondary schema used by this device, that can - be selected by clients (either through NETCONF capability - negotiation or RESTCONF schema specific path)."; - } - - list custom-schema { - if-feature "custom-schema"; - key "name"; - - description - "Defines a custom selectable schema constructed from - compatible schema"; - - leaf name { - type "string"; - description - "Name of custom schema. - - Format can either be the form of a YANG identifer, or - '@'. - - The selectable-schema name is used in NETCONF capabilties - negotiation and also the RESTCONF path (XXX, is encoding - required, e.g. for '@'?)"; - } - - leaf description { - type string; - description - "The description associated with this custom package."; - } - - leaf-list included-schema { - type leafref { - path "/schema-selection/schema/name"; - require-instance false; - } - description - "Lists the schema that are combined together into a single - selectable schema (i.e. via a union operation on each - datastore schema package)."; - } - } - - list schema { - key "name"; - config false; - - description - "All available pan-datastore schema that can be used in schema - version selection."; - - leaf name { - type string; - - description - "Name of the schema. - - Do we restrict what is allowed, specifically, do we allow - '@'"; - } - - list datastores { - key "datastore"; - - description - "The list of datastores supported for this pan-datastore - selectable-package, along with the package schema - associated with that datastore."; - - leaf datastore { - type ds:datastore-ref; - description - "The datastore that this datastore schema is associated - with"; - reference - "RFC 8342: Network Management Datastore Architecture - (NMDA)"; - } - - container package { - description - "YANG package associated with this datastore schema"; - - leaf name { - type leafref { - path "/yanglib:yang-library/yl-pkg:package/yl-pkg:name"; - } - description - "The name of the YANG package this schema relates to"; - } - - leaf version { - type leafref { - path '/yanglib:yang-library/' - + 'yl-pkg:package[yl-pkg:name = current()/../name]/' - + 'yl-pkg:version'; - } - - description - "The version of the YANG package this schema relates - to"; - } - - leaf checksum { - type leafref { - path '/yanglib:yang-library/' - + 'yl-pkg:package[yl-pkg:name = current()/../name]' - + '[yl-pkg:version = current()/../version] ' - + '/yl-pkg:checksum'; - } - - description - "The checksum of the references package."; - } - } - } - - container default-schema-selectable { - if-feature "default-schema"; - presence - "This schema MAY be selected as the device default - schema."; - description - "Defines compatibility if this schema can be selected as a - primary schema."; - - leaf-list compatible-secondary-schema { - type leafref { - path "/schema-selection/schema/name"; - } - description - "Lists other schema that MAY be selected as secondary - schema is this schema is selected as a default-schema."; - } - } - - container secondary-schema-selectable { - if-feature "secondary-schema"; - presence - "This schema MAY be selected as a secondary schema, - selected for a particular session."; - description - "Defines compatibility if this schema can be selected as a - secondary schema."; - - leaf-list compatible-default-schema { - type leafref { - path "/schema-selection/schema/name"; - } - description - "Lists other schema that MAY be selected as the default - schema at ths same time as this schema is selected as a - secondary-schema."; - } - - leaf-list compatible-secondary-schema { - type leafref { - path "/schema-selection/schema/name"; - } - description - "Lists other schema that MAY be selected as other secondary - schema is this schema is selected as a secondary-schema."; - } - } - - container custom-schema-selectable { - if-feature "custom-schema"; - presence - "This schema MAY be selected as part of a custom schema."; - description - "Defines compatibility if this schema can be combined as - part of a custom schema."; - - leaf-list combinable-schema { - type leafref { - path "/schema-selection/schema/name"; - } - description - "Lists the schema that MAY be combined with this - schema into a single custom schema'."; - } - } - } - } -} diff --git a/yang-ver-selection/tmp/ietf-yang-package-instance.yang b/yang-ver-selection/tmp/ietf-yang-package-instance.yang deleted file mode 100644 index 179d252..0000000 --- a/yang-ver-selection/tmp/ietf-yang-package-instance.yang +++ /dev/null @@ -1,91 +0,0 @@ -module ietf-yang-package-instance { - yang-version 1.1; - namespace "urn:ietf:params:xml:ns:yang:ietf-yang-package-instance"; - prefix pkg-inst; - - import ietf-yang-revisions { - prefix rev; - reference "XXXX: Updated YANG Module Revision Handling"; - } - - import ietf-yang-package-types { - prefix pkg-types; - rev:revision-or-derived 0.1.0; - reference "RFC XXX: YANG Schema Versioning."; - } - - import ietf-yang-structure-ext { - prefix sx; - reference "RFC XXX: YANG Data Structure Extensions."; - } - - import ietf-yang-types { - prefix yang; - rev:revision-or-derived 2013-07-15; - reference "RFC 6991: Common YANG Data Types."; - } - - import ietf-inet-types { - prefix inet; - reference "RFC 6991: Common YANG Data Types."; - } - - organization - "IETF NETMOD (Network Modeling) Working Group"; - - contact - "WG Web: - WG List: - - Author: Rob Wilton - "; - - description - "This module provides a definition of a YANG package, which is - used as the schema for an YANG instance data document specifying - a YANG package. - - Copyright (c) 2019 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 XXXX; see - the RFC itself for full legal notices. - - 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."; - - // RFC Ed.: update the date below with the date of RFC publication - // and remove this note. - // RFC Ed.: replace XXXX with actual RFC number and remove this - // note. - revision 2019-12-16 { - rev:revision-label 0.2.0; - description - "Initial revision"; - reference - "RFC XXXX: YANG Packages"; - } - - - /* - * Top-level structure - */ - - sx:structure package { - description - "Defines a YANG package for use on a YANG instance data - document."; - - uses pkg-types:yang-pkg-instance; - } -} diff --git a/yang-ver-selection/tmp/ietf-yang-package-types.yang b/yang-ver-selection/tmp/ietf-yang-package-types.yang deleted file mode 100644 index ea8568a..0000000 --- a/yang-ver-selection/tmp/ietf-yang-package-types.yang +++ /dev/null @@ -1,563 +0,0 @@ -module ietf-yang-package-types { - yang-version 1.1; - namespace "urn:ietf:params:xml:ns:yang:ietf-yang-package-types"; - prefix "pkg-types"; - - import ietf-yang-revisions { - prefix rev; - reference "XXXX: Updated YANG Module Revision Handling"; - } - - import ietf-yang-types { - prefix yang; - rev:revision-or-derived 2013-07-15; - reference "RFC 6991: Common YANG Data Types."; - } - - import ietf-inet-types { - prefix inet; - reference "RFC 6991: Common YANG Data Types."; - } - - import ietf-module-tags { - prefix tags; - reference "RFC XXX: YANG Module Tags."; - } - - organization - "IETF NETMOD (Network Modeling) Working Group"; - - contact - "WG Web: - WG List: - - Author: Rob Wilton - "; - - description - "This module provides type and grouping definitions for YANG - packages. - - Copyright (c) 2019 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 XXXX; see - the RFC itself for full legal notices. - - 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."; - - // RFC Ed.: update the date below with the date of RFC publication - // and remove this note. - // RFC Ed.: replace XXXX with actual RFC number and remove this - // note. - revision 2019-12-16 { - rev:revision-label 0.2.0; - description - "Initial revision"; - reference - "RFC XXXX: YANG Packages"; - } - - - /* - * Typedefs - */ - - typedef pkg-name { - type yang:yang-identifier; - description - "Package names are typed as YANG identifiers."; - } - - typedef pkg-version { - type rev:revision-date-or-label; - description - "Package versions SHOULD be a revision-label (e.g. perhaps a - YANG Semver version string). Package versions MAY also be a - revision-date"; - - } - - typedef pkg-identifier { - type rev:name-revision; - description - "Package identifiers combine a pkg-name and a pkg-version"; - } - - typedef scoped-feature { - type string { - pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*:[a-zA-Z_][a-zA-Z0-9\-_.]*'; - } - description - "Represents a feature name scoped to a particular module, - identified as the ':', where both - and are YANG identifier strings, - as defiend by Section 12 or RFC 6020."; - reference - "RFC XXXX, YANG Packages."; - } - - typedef sha-256-hash { - type string { - length "64"; - pattern "[0-9a-fA-F]*"; - } - description - "A SHA-256 hash represented as a hexadecimal string. - - Used as the checksum for modules, submodules and packages in a - YANG package definition. - - For modules and submodules the SHA-256 hash is calculated on - the contents of the YANG file defining the module/submodule. - - For packages the SHA-256 hash is calculated on the file - containing the YANG instance data document holding the package - definition"; - } - - - /* - * Groupings - */ - grouping yang-pkg-compact-identification-leaf { - description - "Parameters to identify a specific version of a YANG package"; - - leaf identifier { - type pkg-identifier; - mandatory true; - description - "The YANG package name and revision (which could be a revision - date, or a revision label, such as a YANG semantic version - number). - - Examples 'foo-pkg' or 'foo-pkg@1.2.3'."; - } - } - - grouping yang-pkg-full-identification-leafs { - description - "Parameters for identifying a specific version of a YANG - package"; - - leaf name { - type pkg-name; - mandatory true; - description - "The YANG package name."; - } - - leaf version { - type pkg-version; - mandatory true; - description - "Uniquely identies a particular version of a YANG package. - - Follows the definition for revision labels defined in - draft-verdt-nemod-yang-module-versioning, section XXX"; - } - } - - grouping yang-pkg-common-leafs { - description - "Defines definitions common to all YANG package definitions."; - - leaf timestamp { - type yang:date-and-time; - - description - "An optional timestamp for when this package was created. - This does not need to be unique across all versions of a - package."; - } - - leaf organization { - type string; - - description "Organization responsible for this package"; - } - - leaf contact { - type string; - - description - "Contact information for the person or organization to whom - queries concerning this package should be sent."; - } - - leaf description { - type string; - - description "Provides a description of the package"; - } - - leaf reference { - type string; - - description "Allows for a reference for the package"; - } - - leaf complete { - type boolean; - default true; - description - "Indicates whether the schema defined by this package is - referentially complete. I.e. all module imports can be - resolved to a module explicitly defined in this package or - one of the included packages."; - } - - leaf local { - type boolean; - default false; - description - "Defines that the package definition is local to the server, - and the name of the package MAY not be unique, and the - package definition MAY not be available in an offline file. - - Local packages can be used when the schema for the device - can be changed at runtime through the addition or removal of - software packages, or hot fixes."; - } - - leaf previous-version { - type pkg-version; - description - "The previous package version that this version has been - derived from. This leaf allows a full version history graph - to be constructed if required."; - } - - leaf nbc-changes { - type boolean; - default false; - description - "Indicates whether the defined package version contains - non-backwards-compatible changes relative to the package - version defined in the 'previous-version' leaf."; - } - - leaf-list tag { - type tags:tag; - description - "Tags associated with a YANG package. Module tags defined in - XXX, ietf-netmod-module-tags can be used here but with the - modification that the tag applies to the entire package - rather than a specific module. See the IANA 'YANG Module - Tag Prefix' registry for reserved prefixes and the IANA - 'YANG Module IETF Tag' registry for IETF standard tags."; - } - - leaf-list mandatory-feature { - type scoped-feature; - description - "Lists features from any modules included in the package that - MUST be supported by any server implementing the package. - - Features already specified in a 'mandatory-feature' list of - any included package MUST also be supported by server - implementations and do not need to be repeated in this list. - - All other features defined in modules included in the - package are OPTIONAL to implement. - - Features are identified using :"; - } - - list included-package { - key "name version"; - description - "An entry in this list represents a package that is included - as part of the package definition, or an indirectly included - package that is changed in a non backwards compatible way. - - It can be used to resolve inclusion of conflicting package - versions by explicitly specifying which package version is - used. - - If included packages implement different revisions or - versions of the same module, then an explicit entry in the - module list MUST be provided to select the specific module - version 'implemented' by this package definition. - - If the schema for any packages that are included, either - directly or indirectly via another package include, are - changed in any non-backwards-compatible way then they MUST - be explicitly listed in the included-packages list with the - 'nbc-modified' leaf set to true. - - For import-only modules, the 'replaces-revision' leaf-list - can be used to select the specific module versions used by - this package."; - reference - "XXX"; - - uses yang-pkg-full-identification-leafs; - - leaf-list replaces-version { - type pkg-version; - description - "Gives the version of an included package version that - is replaced by this included package revision."; - } - - leaf nbc-modified { - type boolean; - default false; - description - "Set to true if any data nodes in this package are modified - in a non backwards compatible way, either through the use - of deviations, or because one of the modules has been - replaced by an incompatible revision. This could also - occur if a module's revision was replaced by an earlier - revision that had the effect of removing some data - nodes."; - } - - leaf-list location { - type inet:uri; - description - "Contains a URL that represents where an instance data file - for this YANG package can be found. - - This leaf will only be present if there is a URL available - for retrieval of the schema for this entry. - - If multiple locations are provided, then the first - location in the leaf-list MUST be the definitive location - that uniquely identifies this package"; - } - - leaf checksum { - type pkg-types:sha-256-hash; - description - "The SHA-256 hash calculated on the textual package - definition, represented as a hexadecimal string."; - } - } - } - - grouping yang-pkg-module-leafs { - list module { - key "name"; - description - "An entry in this list represents a module that must be - implemented by a server implementing this package, as per - RFC 7950 section 5.6.5, with a particular set of supported - features and deviations. - - A entry in this list overrides any module revision - 'implemented' by an included package. Any replaced module - revision SHOULD also be listed in the 'replaces-revision' - list."; - reference - "RFC 7950: The YANG 1.1 Data Modeling Language."; - - leaf name { - type yang:yang-identifier; - mandatory true; - description - "The YANG module name."; - } - - leaf revision { - type rev:revision-date-or-label; - description - "The YANG module revision date or revision-label. - - If no revision statement is present in the YANG module, - this leaf is not instantiated."; - } - - leaf-list replaces-revision { - type rev:revision-date-or-label; - description - "Gives the revision of an module (implemented or - import-only) defined in an included package that is - replaced by this implemented module revision."; - } - - leaf namespace { - type inet:uri; - description - "The XML namespace identifier for this module."; - } - - leaf-list location { - type inet:uri; - description - "Contains a URL that represents the YANG schema resource - for this module. - - This leaf will only be present if there is a URL available - for retrieval of the schema for this entry."; - } - - leaf checksum { - type pkg-types:sha-256-hash; - description - "The SHA-256 hash calculated on the textual module - definition, represented as a hexadecimal string."; - } - - list submodule { - key "name"; - description - "Each entry represents one submodule within the - parent module."; - - leaf name { - type yang:yang-identifier; - description - "The YANG submodule name."; - } - - leaf revision { - type yang:revision-identifier; - mandatory true; - description - "The YANG submodule revision date. If the parent module - include statement for this submodule includes a revision - date then it MUST match this leaf's value."; - } - - leaf-list location { - type inet:uri; - description - "Contains a URL that represents the YANG schema resource - for this submodule. - - This leaf will only be present if there is a URL - available for retrieval of the schema for this entry."; - } - - leaf checksum { - type pkg-types:sha-256-hash; - description - "The SHA-256 hash calculated on the textual submodule - definition, represented as a hexadecimal string."; - } - } - } - - list import-only-module { - key "name revision"; - description - "An entry in this list indicates that the server imports - reusable definitions from the specified revision of the - module, but does not implement any protocol accessible - objects from this revision. - - Multiple entries for the same module name MAY exist. This - can occur if multiple modules import the same module, but - specify different revision-dates in the import statements."; - - leaf name { - type yang:yang-identifier; - description - "The YANG module name."; - } - - leaf revision { - type rev:revision-date-or-label; - description - "The YANG module revision date or revision-label. - - If no revision statement is present in the YANG module, - this leaf is not instantiated."; - } - - leaf-list replaces-revision { - type rev:revision-date-or-label; - description - "Gives the revision of an import-only-module defined in an - included package that is replaced by this - import-only-module revision."; - } - - leaf namespace { - type inet:uri; - description - "The XML namespace identifier for this module."; - } - - leaf-list location { - type inet:uri; - description - "Contains a URL that represents the YANG schema resource - for this module. - - This leaf will only be present if there is a URL available - for retrieval of the schema for this entry."; - } - - leaf checksum { - type pkg-types:sha-256-hash; - description - "The SHA-256 hash calculated on the textual submodule - definition, represented as a hexadecimal string."; - } - - list submodule { - key "name"; - description - "Each entry represents one submodule within the - parent module."; - - leaf name { - type yang:yang-identifier; - description - "The YANG submodule name."; - } - - leaf revision { - type yang:revision-identifier; - mandatory true; - description - "The YANG submodule revision date. If the parent module - include statement for this submodule includes a revision - date then it MUST match this leaf's value."; - } - - leaf-list location { - type inet:uri; - description - "Contains a URL that represents the YANG schema resource - for this submodule. - - This leaf will only be present if there is a URL - available for retrieval of the schema for this entry."; - } - - leaf checksum { - type pkg-types:sha-256-hash; - description - "The SHA-256 hash calculated on the textual submodule - definition, represented as a hexadecimal string."; - } - } - } - } - - grouping yang-pkg-instance { - description - "Specifies the data node for a full YANG package instance - represented either on a server or a YANG instance data - document."; - uses yang-pkg-full-identification-leafs; - uses yang-pkg-common-leafs; - uses yang-pkg-module-leafs; - } -} diff --git a/yang-ver-selection/tmp/ietf-yang-revisions.yang b/yang-ver-selection/tmp/ietf-yang-revisions.yang deleted file mode 100644 index 1dd592f..0000000 --- a/yang-ver-selection/tmp/ietf-yang-revisions.yang +++ /dev/null @@ -1,218 +0,0 @@ -module ietf-yang-revisions { - yang-version 1.1; - namespace "urn:ietf:params:xml:ns:yang:ietf-yang-revisions"; - prefix rev; - - import ietf-yang-types { - prefix yang; - reference - "XXXX [ietf-netmod-rfc6991-bis]: Common YANG Data Types"; - } - - organization - "IETF NETMOD (Network Modeling) Working Group"; - contact - "WG Web: - WG List: - - Author: Benoit Claise - - - Author: Joe Clarke - - - Author: Reshad Rahman - - - Author: Robert Wilton - - - Author: Kevin D'Souza - - - Author: Balazs Lengyel - - - Author: Jason Sterne - "; - description - "This YANG 1.1 module contains definitions and extensions to - support updated YANG revision handling. - - Copyright (c) 2019 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 XXXX; see - the RFC itself for full legal notices. - - 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."; - - // RFC Ed.: update the date below with the date of RFC publication - // and remove this note. - // RFC Ed.: replace XXXX (inc above) with actual RFC number and - // remove this note. - - revision 2019-09-18 { - description - "Initial version."; - reference - "XXXX: Updated YANG Module Revision Handling"; - } - - typedef revision-label { - type string { - length "1..255"; - pattern '[^\s@]+'; - pattern '\d{4}-\d{2}-\d{2}' { - modifier invert-match; - } - } - description - "A label associated with a YANG revision. - - Excludes spaces and '@'. MUST NOT match revision-date. - - Revision labels that classify as YANG semantic versions, - as defined by the ietf-yang-semver:version typedef, - MUST conform to the versioning behaviour defined in - XXXX [verdt]: YANG Semantic Versioning."; - reference - "XXXX: Updated YANG Module Revision Handling; - Section 3.3, Revision label"; - } - - typedef name-revision { - type string { - length "1..512"; - pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*(@[^\s@]+)?'; - pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*'; - } - description - "Identifies a particular revision of a YANG asset (e.g. module - or package). - - Takes the form '' or '@', where - could be either a revision-date or a revision label."; - } - - typedef revision-date-or-label { - type union { - type yang:revision-identifier; - type revision-label; - } - description - "Represents either a YANG revision date or a revision label"; - } - - extension nbc-changes { - description - "This statement is used to indicate YANG module revisions that - contain non-backwards-compatible changes. - - Each 'revision' statement MAY have a single 'nbc-changes' - substatement. - - If a revision of a YANG module contains changes, relative to - the preceding revision in the revision history, that do not - conform to the module update rules defined in RFC-XXX, then - the 'nbc-changes' statement MUST be added as a substatement to - the revision statement. - - Conversely, if a revision of a YANG module only contains - changes, relative to the preceding revision in the revision - history, that are classified as 'backwards-compatible' then - the revision statement MUST NOT contain any 'nbc-changes' - substatement."; - - reference - "XXXX: Updated YANG Module Revision Handling; - Section 3.2, nbc-changes revision extension statement"; - } - - extension revision-label { - argument revision-label; - description - "The revision label can be used to provide an additional - versioning identifier associated with the revision. E.g., one - option for a versioning scheme that could be used is [TODO - - Reference semver draft]. - - The format of the revision-label argument MUST conform to the - pattern defined for the revision-label typedef. - - Each 'revision' statement MAY have a single 'revision-label' - substatement. - - Revision labels MUST be unique amongst all revisions of a - module."; - - reference - "XXXX: Updated YANG Module Revision Handling; - Section 3.3, Revision label"; - } - - extension revision-or-derived { - argument revision-date-or-label; - description - "Restricts the revision of the module that may be imported to - one that matches or is derived from the specified - revision-date or revision-ñlabel. - - The argument value MUST conform to the - 'revision-date-or-label' defined type. - - Each 'import' statement MAY have one or more - 'revision-or-derived' substatements. If specified multiple - times, then any module revision that satifies at least one of - the 'revision-or-derived' statements is an acceptable revision - for import. - - An 'import' statement MUST NOT contain both a - 'revision-or-derived' extension statement and a - 'revision-date' statement. - - A particular revision of an imported module satisfies an - import's 'revision-or-derived' extension statement if the - imported module's revision history contains a revision - statement with a matching revision date or revision label. - - The 'revision-or-derived' extension statement does not - gaurantee that all module revisions that satisfy an import - statement are necessarily compatible, it only gives an - indication that the revisions are more likely to be - compatible."; - - reference - "XXXX: Updated YANG Module Revision Handling; - Section 4, Import by derived revision"; - } - - extension status-description { - argument description; - - description - "Freeform text that describes why a given node has been - deprecated or made obsolete. E.g., the description could be - used to give the reason for removal, or it could point to an - alternative schema elements that can be used in lieu of the - given node. - - Each 'status' statement MAY have a single 'status-description' - substatement."; - - reference - "XXXX: Updated YANG Module Revision Handling; - Section 3.4, YANG status description extension statement"; - } -} diff --git a/yang-ver-selection/tmp/ietf-yang-structure-ext@2019-03-07.yang b/yang-ver-selection/tmp/ietf-yang-structure-ext@2019-03-07.yang deleted file mode 100644 index 1ca7a89..0000000 --- a/yang-ver-selection/tmp/ietf-yang-structure-ext@2019-03-07.yang +++ /dev/null @@ -1,204 +0,0 @@ -module ietf-yang-structure-ext { - yang-version 1.1; - namespace "urn:ietf:params:xml:ns:yang:ietf-yang-structure-ext"; - prefix sx; - - organization - "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; - contact - "WG Web: - WG List: - - Author: Andy Bierman - - - Author: Martin Bjorklund - - - Author: Kent Watsen - "; - description - "This module contains conceptual YANG specifications for defining - abstract data structures. - - 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) 2019 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)."; - - // RFC Ed.: update the date below with the date of RFC publication - // and remove this note. - - revision 2019-03-07 { - description - "Initial revision."; - // RFC Ed.: replace XXXX with RFC number and remove this note - reference - "RFC XXXX: YANG Structure Extensions."; - } - - extension structure { - argument name { - yin-element true; - } - description - "This extension is used to specify a YANG data structure that - represents conceptual data defined in YANG. It is intended to - describe hierarchical data independent of protocol context or - specific message encoding format. Data definition statements - within a 'structure' extension statement specify the generic - syntax for the specific YANG data structure, whose name is the - argument of the 'structure' extension statement. - - Note that this extension does not define a media-type. A - specification using this extension MUST specify the message - encoding rules, including the content media type, if - applicable. - - The mandatory 'name' parameter value identifies the YANG data - structure that is being defined. - - This extension is only valid as a top-level statement, i.e., - given as a sub-statement to 'module' or 'submodule'. - The sub-statements of this extension MUST follow the ABNF - rules below, where the rules are defined in RFC 7950: - - *must-stmt - [status-stmt] - [description-stmt] - [reference-stmt] - *(typedef-stmt / grouping-stmt) - *data-def-stmt - - A YANG data structure defined with this extension statement is - encoded in the same way as an 'anydata' statement. This means - that the name of the structure is encoded as a 'container', - with the instantiated child statements encoded as child nodes - to this node. - - The module name and namespace value for the YANG module using - the extension statement is assigned to each of the data - definition statements resulting from the YANG data structure. - - The XPath document element is the extension statement itself, - such that the child nodes of the document element are - represented by the data-def-stmt sub-statements within this - extension. This conceptual document is the context for the - following YANG statements: - - - must-stmt - - when-stmt - - path-stmt - - min-elements-stmt - - max-elements-stmt - - mandatory-stmt - - unique-stmt - - ordered-by - - instance-identifier data type - - The following data-def-stmt sub-statements are constrained - when used within a 'structure' extension statement. - - - The list-stmt is not required to have a key-stmt defined. - - The config-stmt is ignored if present. - "; - } - - extension augment-structure { - argument path { - yin-element true; - } - description - "This extension is used to specify an augmentation to YANG data - structure defined with the 'structure' statement. It is - intended to describe hierarchical data independent of protocol - context or specific message encoding format. - - This statement has almost the same structure as the - 'augment-stmt'. Data definition statements within this - statement specify the semantics and generic syntax for the - additional data to be added to the specific YANG data - structure, identified by the 'path' argument. - - The mandatory 'path' parameter value identifies the YANG - conceptual data node that is being augmented, represented as - an absolute-schema-nodeid string, where the first node in the - absolute-schema-nodeid string identifies the YANG data - structure to augment, and the rest of the nodes in the string - identifies the node within the YANG structure to augment. - - This extension is only valid as a top-level statement, i.e., - given as a sub-statement to 'module' or 'submodule'. - - The sub-statements of this extension MUST follow the ABNF - rules below, where the rules are defined in RFC 7950: - - [status-stmt] - [description-stmt] - [reference-stmt] - 1*(data-def-stmt / case-stmt) - - The module name and namespace value for the YANG module using - the extension statement is assigned to instance document data - conforming to the data definition statements within this - extension. - - The XPath document element is the augmented extension - statement itself, such that the child nodes of the document - element are represented by the data-def-stmt sub-statements - within the augmented 'structure' statement. - - The context node of the 'augment-structure' statement is - derived in the same way as the 'augment' statement, as defined - in section 6.4.1 of [RFC7950]. This conceptual node is - considered the context node for the following YANG statements: - - - must-stmt - - when-stmt - - path-stmt - - min-elements-stmt - - max-elements-stmt - - mandatory-stmt - - unique-stmt - - ordered-by - - instance-identifier data type - - The following data-def-stmt sub-statements are constrained - when used within an 'augment-structure' extension statement. - - - The list-stmt is not required to have a key-stmt defined. - - The config-stmt is ignored if present. - - Example: - - module foo { - import ietf-yang-structure-ext { prefix sx; } - - sx:structure foo-data { - container foo-con { } - } - } - - module bar { - import ietf-yang-structure-ext { prefix sx; } - import foo { prefix foo; } - - sx:augment-structure /foo:foo-data/foo:foo-con { - leaf add-leaf1 { type int32; } - leaf add-leaf2 { type string; } - } - } - "; - } -} diff --git a/yang-ver-selection/tmp/ietf-yang-types@2019-07-21.yang b/yang-ver-selection/tmp/ietf-yang-types@2019-07-21.yang deleted file mode 100644 index 3d5db3e..0000000 --- a/yang-ver-selection/tmp/ietf-yang-types@2019-07-21.yang +++ /dev/null @@ -1,717 +0,0 @@ -module ietf-yang-types { - - namespace "urn:ietf:params:xml:ns:yang:ietf-yang-types"; - prefix "yang"; - - organization - "IETF Network Modeling (NETMOD) Working Group"; - - contact - "WG Web: - WG List: - - Editor: Juergen Schoenwaelder - "; - - description - "This module contains a collection of generally useful derived - YANG data types. - - The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL - NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', - 'MAY', and 'OPTIONAL' in this document are to be interpreted as - described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, - they appear in all capitals, as shown here. - - Copyright (c) 2019 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 XXXX; - see the RFC itself for full legal notices."; - - revision 2019-07-21 { - description - "This revision adds the following new data types: - - date, time - - hours, minutes, seconds - - centiseconds, milliseconds, microseconds, nanoseconds - - revision-identifier, node-instance-identifier"; - reference - "RFC XXXX: Common YANG Data Types"; - } - - 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 instantiation of - a schema node of type counter32 at times other than - re-initialization, then a corresponding schema node - should be defined, with an appropriate type, to indicate - the last discontinuity. - The counter32 type should not be used for configuration - schema nodes. A default statement SHOULD NOT be used in - combination with the type counter32. - - In the value set and its semantics, this type is equivalent - to the Counter32 type of the SMIv2."; - reference - "RFC 2578: Structure of Management Information Version 2 - (SMIv2)"; - } - - typedef zero-based-counter32 { - type yang: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) - 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 - actual time between polls, and to discard data if the actual - time is too long or there is no defined minimum time. - - In the value set and its semantics, this type is equivalent - to the ZeroBasedCounter32 textual convention of the SMIv2."; - reference - "RFC 4502: Remote Network Monitoring Management Information - Base Version 2"; - } - - typedef counter64 { - type uint64; - description - "The counter64 type represents a non-negative integer - that monotonically increases until it reaches a - maximum value of 2^64-1 (18446744073709551615 decimal), - when it wraps around and starts increasing again from zero. - - Counters have no defined 'initial' value, and thus, a - single value of a counter has (in general) no information - content. Discontinuities in the monotonically increasing - value normally occur at re-initialization of the - management system, and at other times as specified in the - description of a schema node using this type. If such - other times can occur, for example, the instantiation of - a schema node of type counter64 at times other than - re-initialization, then a corresponding schema node - should be defined, with an appropriate type, to indicate - the last discontinuity. - - The counter64 type should not be used for configuration - schema nodes. A default statement SHOULD NOT be used in - combination with the type counter64. - - In the value set and its semantics, this type is equivalent - to the Counter64 type of the SMIv2."; - reference - "RFC 2578: Structure of Management Information Version 2 - (SMIv2)"; - } - - typedef zero-based-counter64 { - type yang: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) - 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 - 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)"; - } - - /*** 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 date-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 date { - type string { - pattern '\d{4}-\d{2}-\d{2}' - + '(Z|[\+\-]\d{2}:\d{2})'; - } - description - "The date type represents a time-interval of the length - of a day, i.e., 24 hours. - - The date type is compatible with the date XML schema - type with the following notable exceptions: - - (a) The date type does not allow negative years. - - (b) The date 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 date. - - (c) The canonical format (see below) of data values - differs from the canonical format used by the date XML - schema type, which requires all times to be in UTC using - the time-offset 'Z'. - - The canonical format for date values with a known time - zone uses a numeric time zone offset that is calculated using - the device's configured known offset to UTC time. A change of - the device's offset to UTC time will cause date values - to change accordingly. Such changes might happen periodically - in case a server follows automatically daylight saving time - (DST) time zone offset changes. The canonical format for - date values 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 - XSD-TYPES: XML Schema Part 2: Datatypes Second Edition"; - } - - /* - * DISCUSS: - * - XML schema seems to use a different canonical format, we - * need to take a closer look how to define the canonical format - * given that a data really identifies a 24 hour interval and - * what XSD means with 'interval midpoint'. - */ - - typedef time { - type string { - pattern '\d{2}:\d{2}:\d{2}(\.\d+)?' - + '(Z|[\+\-]\d{2}:\d{2})'; - } - description - "The time type represents an instance of time of zero-duration - that recurs every day. - - The time type is compatible with the time XML schema - type with the following notable exceptions: - - (a) The 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 time. - - (c) The canonical format (see below) of time values - differs from the canonical format used by the time XML - schema type, which requires all times to be in UTC using - the time-offset 'Z'. - - The canonical format for time values with a known time - zone uses a numeric time zone offset that is calculated using - the device's configured known offset to UTC time. A change of - the device's offset to UTC time will cause time values - to change accordingly. Such changes might happen periodically - in case a server follows automatically daylight saving time - (DST) time zone offset changes. The canonical format for - time values 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 - XSD-TYPES: XML Schema Part 2: Datatypes Second Edition"; - } - - typedef hours { - type uint32; - units "hours"; - description - "A period of time, measured in units of hours."; - } - - typedef minutes { - type uint32; - units "minutes"; - description - "A period of time, measured in units of minutes."; - } - - typedef seconds { - type uint32; - units "seconds"; - description - "A period of time, measured in units of seconds. - The maximum duration that can be expressed is in the - order of 49710 days and 6 hours and 28 minutes and 15 - seconds."; - } - - typedef centiseconds { - type uint32; - units "centiseconds"; - description - "A period of time, measured in units of 10^-2 seconds. - The maximum duration that can be expressed is in the - order of 497 days and 2 hours and 27 minutes and 52 - seconds."; - } - - typedef milliseconds { - type uint32; - units "milliseconds"; - description - "A period of time, measured in units of 10^-3 seconds. - The maximum duration that can be expressed is in the - order of 49 days and 17 hours and 2 minutes and 47 - seconds."; - } - - typedef microseconds { - type uint32; - units "microseconds"; - description - "A period of time, measured in units of 10^-6 seconds. - The maximum duration that can be expressed is in the - order of 1 hour and 11 minutes and 34 seconds."; - } - - typedef nanoseconds { - type uint32; - units "nanoseconds"; - description - "A period of time, measured in units of 10^-9 seconds. - The maximum duration that can be expressed is in the - order of 4 seconds."; - } - - /* - * DISCUSS: - * - do we need (nano|micro|milli)seconds with 64 bits? - * - do we add typedef timeinterval { type centiseconds - * { range 0..2147483647 } } for compatibility with SMIv2? - * - some modules use negative minutes, do we care? A _duration_ - * does likely not need negative values. However, if minutes are - * used to represent a relative time offset, then negative minutes - * do make sense. Do we have to support durations as well as - * time offsets? - */ - - 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 instance at which a specific occurrence - happened. The specific occurrence must be defined in the - description of any schema node defined using this type. When - the specific occurrence occurred prior to the last time the - associated timeticks schema node instance was zero, then the - timestamp value is zero. - - Note that this requires all timestamp values to be reset to - zero when the value of the associated timeticks schema node - instance reaches 497+ days and wraps around to zero. - - The associated timeticks schema node must be specified - in the description of any schema node using this type. - - In the value set and its semantics, this type is equivalent - to the TimeStamp textual convention of the SMIv2."; - reference - "RFC 2579: Textual Conventions for SMIv2"; - } - - /*** collection of generic address types ***/ - - typedef phys-address { - type string { - pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?'; - } - description - "Represents media- or physical-level addresses represented - as a sequence octets, each octet represented by two hexadecimal - numbers. Octets are separated by colons. The canonical - representation uses lowercase characters. - - In the value set and its semantics, this type is equivalent - to the PhysAddress textual convention of the SMIv2."; - reference - "RFC 2579: Textual Conventions for SMIv2"; - } - - typedef mac-address { - type string { - pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}'; - } - description - "The mac-address type represents 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"; - } - - /* - * DISCUSS: - * - How do we deal with xpath expressions in other encodings - * such as JSON. Do we assume an xpath context populated with - * module names such that module names can be used to qualify - * path expressions. This may need discussion and/or a new - * definition. - * - This interacts with the definition of node-instance-identifier. - */ - - /*** 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."; - } - - /*** collection of YANG specific types ***/ - - 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)"; - } - - typedef revision-identifier { - type date { - pattern '\d{4}-\d{2}-\d{2}'; - } - description - "Represents a specific revision of a YANG module by means of - a date value without a time zone."; - } - - typedef node-instance-identifier { - type xpath1.0; - description - "Path expression used to represent a special - data node, action, or notification instance-identifier - string. - - A node-instance-identifier value is an - unrestricted YANG instance-identifier expression. - - All the same rules as an instance-identifier apply, - except that predicates for keys are optional. If a key - predicate is missing, then the node-instance-identifier - represents all possible server instances for that key. - - This XML Path Language (XPath) expression is evaluated in the - following context: - - o The set of namespace declarations are those in scope on - the leaf element where this type is used. - - o The set of variable bindings contains one variable, - 'USER', which contains the name of the user of the - current session. - - o The function library is the core function library, but - note that due to the syntax restrictions of an - instance-identifier, no functions are allowed. - - o The context node is the root node in the data tree. - - The accessible tree includes actions and notifications tied - to data nodes."; - } - - /* - * DISCUSS: - * - This is taken from RFC 8341 and the idea is that this definition - * is useful without requiring a dependency on NACM - * - What does the second bullet actually do? Do we keep this? - * - How does this work with JSON? Can we make this encoding neutral - * (but then we knowingly depart from NACM)? - * - This interacts with the definition of xpath1.0. - */ - - /* DISCUSS: - * - It was suggested to add types for longitude, latitude, - * postal code, country-code. Do we go there or do we leave - * these for other modules to define? It seems such definitions - * should go into draft-ietf-netmod-geo-location. - */ - - /* DISCUSS: - * - It was suggested to add percentage types but they tend to differ - * widely. However, percentages are also widely used. - */ -} diff --git a/yang-ver-selection/tmp/ietf-yl-packages.yang b/yang-ver-selection/tmp/ietf-yl-packages.yang deleted file mode 100644 index 5f81a12..0000000 --- a/yang-ver-selection/tmp/ietf-yl-packages.yang +++ /dev/null @@ -1,157 +0,0 @@ -module ietf-yl-packages { - yang-version 1.1; - namespace "urn:ietf:params:xml:ns:yang:ietf-yl-packages"; - prefix yl-pkg; - - import ietf-yang-revisions { - prefix rev; - reference "XXXX: Updated YANG Module Revision Handling"; - } - - import ietf-yang-package-types { - prefix pkg-types; - reference "RFC XXX: YANG Packages."; - } - - import ietf-yang-library { - prefix yanglib; - reference "RFC 8525: YANG Library"; - } - - import ietf-inet-types { - prefix inet; - reference "RFC 6991: Common YANG Data Types."; - } - - organization - "IETF NETMOD (Network Modeling) Working Group"; - - contact - "WG Web: - WG List: - - Author: Rob Wilton - "; - - description - "This module provides defined augmentations to YANG library to - allow a server to report YANG package information. - - Copyright (c) 2018 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 XXXX; see - the RFC itself for full legal notices. - - 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."; - - - // RFC Ed.: update the date below with the date of RFC publication - // and remove this note. - // RFC Ed.: replace XXXX with actual RFC number and remove this - // note. - revision 2019-09-11 { - rev:revision-label 0.1.0; - description - "Initial revision"; - reference - "RFC XXXX: YANG Packages"; - } - - - /* - * Augmentations - */ - - augment "/yanglib:yang-library" { - description "Add YANG package definitions into YANG library"; - - list package { - key "name version"; - - description - "YANG package instance"; - - uses pkg-types:yang-pkg-instance; - - leaf-list location { - type inet:uri; - description - "Contains a URL that represents where an instance data file - for this YANG package can be found. - - This leaf will only be present if there is a URL available - for retrieval of the schema for this entry. - - If multiple locations are provided, then the first location - in the leaf-list MUST be the definitive location that - uniquely identifies this package"; - } - - leaf checksum { - type pkg-types:sha-256-hash; - description - "The checksum of the package this schema relates to, - calculated on the 'YANG instance data file' package - definition. - - This leaf MAY be omitted if the referenced package is - locally scoped without an associated checksum."; - } - } - } - - augment "/yanglib:yang-library/yanglib:schema" { - description - "Allow datastore schema to be related to a YANG package"; - - container package { - leaf name { - type leafref { - path "/yanglib:yang-library/package/name"; - } - description - "The name of the package this schema relates to. - - The referenced package MUST represent a referentially - complete schema"; - } - - leaf version { - type leafref { - path '/yanglib:yang-library/' - + 'package[name = current()/../name]/version'; - } - - description - "The package version number this schema relates to."; - } - - leaf checksum { - type leafref { - path '/yanglib:yang-library/' - + 'package[name = current()/../name]' - + '[version = current()/../version]/checksum'; - } - - description - "The checksum of the referenced package."; - } - - description - "Describes which package the schema directly relates to, if - any."; - } - } -}