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.";
- }
- }
-}