Fix xpath building for data nodes addressing YANG augmentation

Issue-ID: CPS-316
Change-Id: I8aa0960c2a6af2b8fe5bc2fb90efe36baee7a881
Signed-off-by: Ruslan Kashapov <ruslan.kashapov@pantheon.tech>

7 files changed, 1987 insertions, 0 deletions

diff --git a/cps-service/src/test/resources/ietf/data/ietf-network-topology-sample-rfc8345.json b/cps-service/src/test/resources/ietf/data/ietf-network-topology-sample-rfc8345.json
new file mode 100644
index 0000000000..8f2ee022cb
--- /dev/null
+++ b/cps-service/src/test/resources/ietf/data/ietf-network-topology-sample-rfc8345.json
@@ -0,0 +1,120 @@
+{
+     "ietf-network:networks": {
+       "network": [
+         {
+           "network-types": {
+           },
+           "network-id": "otn-hc",
+           "node": [
+             {
+               "node-id": "D1",
+               "termination-point": [
+                 {
+                   "tp-id": "1-0-1"
+                 },
+                 {
+                   "tp-id": "1-2-1"
+                 },
+                 {
+                   "tp-id": "1-3-1"
+                 }
+               ]
+             },
+             {
+               "node-id": "D2",
+               "termination-point": [
+                 {
+                   "tp-id": "2-0-1"
+                 },
+                 {
+                   "tp-id": "2-1-1"
+                 },
+                 {
+                   "tp-id": "2-3-1"
+                 }
+               ]
+             },
+             {
+               "node-id": "D3",
+               "termination-point": [
+                 {
+                   "tp-id": "3-1-1"
+                 },
+                 {
+                   "tp-id": "3-2-1"
+                 }
+               ]
+             }
+           ],
+           "ietf-network-topology:link": [
+             {
+               "link-id": "D1,1-2-1,D2,2-1-1",
+               "source": {
+                 "source-node": "D1",
+                 "source-tp": "1-2-1"
+               },
+               "destination": {
+                 "dest-node": "D2",
+                 "dest-tp": "2-1-1"
+               }
+             },
+             {
+               "link-id": "D2,2-1-1,D1,1-2-1",
+               "source": {
+                 "source-node": "D2",
+                 "source-tp": "2-1-1"
+               },
+               "destination": {
+                 "dest-node": "D1",
+                 "dest-tp": "1-2-1"
+               }
+             },
+             {
+               "link-id": "D1,1-3-1,D3,3-1-1",
+               "source": {
+                 "source-node": "D1",
+                 "source-tp": "1-3-1"
+               },
+               "destination": {
+                 "dest-node": "D3",
+                 "dest-tp": "3-1-1"
+               }
+             },
+             {
+               "link-id": "D3,3-1-1,D1,1-3-1",
+               "source": {
+                 "source-node": "D3",
+                 "source-tp": "3-1-1"
+               },
+               "destination": {
+                 "dest-node": "D1",
+                 "dest-tp": "1-3-1"
+               }
+             },
+             {
+               "link-id": "D2,2-3-1,D3,3-2-1",
+               "source": {
+                 "source-node": "D2",
+                 "source-tp": "2-3-1"
+               },
+               "destination": {
+                 "dest-node": "D3",
+                 "dest-tp": "3-2-1"
+               }
+             },
+             {
+               "link-id": "D3,3-2-1,D2,2-3-1",
+               "source": {
+                 "source-node": "D3",
+                 "source-tp": "3-2-1"
+               },
+               "destination": {
+                 "dest-node": "D2",
+                 "dest-tp": "2-3-1"
+               }
+             }
+           ]
+         }
+       ]
+     }
+   }
diff --git a/cps-service/src/test/resources/ietf/ietf-inet-types@2013-07-15.yang b/cps-service/src/test/resources/ietf/ietf-inet-types@2013-07-15.yang
new file mode 100644
index 0000000000..eacefb6363
--- /dev/null
+++ b/cps-service/src/test/resources/ietf/ietf-inet-types@2013-07-15.yang
@@ -0,0 +1,458 @@
+module ietf-inet-types {
+
+  namespace "urn:ietf:params:xml:ns:yang:ietf-inet-types";
+  prefix "inet";
+
+  organization
+   "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
+
+  contact
+   "WG Web:   <http://tools.ietf.org/wg/netmod/>
+    WG List:  <mailto:netmod@ietf.org>
+
+    WG Chair: David Kessens
+              <mailto:david.kessens@nsn.com>
+
+    WG Chair: Juergen Schoenwaelder
+              <mailto:j.schoenwaelder@jacobs-university.de>
+
+    Editor:   Juergen Schoenwaelder
+              <mailto:j.schoenwaelder@jacobs-university.de>";
+
+  description
+   "This module contains a collection of generally useful derived
+    YANG data types for Internet addresses and related things.
+
+    Copyright (c) 2013 IETF Trust and the persons identified as
+    authors of the code.  All rights reserved.
+
+    Redistribution and use in source and binary forms, with or
+    without modification, is permitted pursuant to, and subject
+    to the license terms contained in, the Simplified BSD License
+    set forth in Section 4.c of the IETF Trust's Legal Provisions
+    Relating to IETF Documents
+    (http://trustee.ietf.org/license-info).
+
+    This version of this YANG module is part of RFC 6991; see
+    the RFC itself for full legal notices.";
+
+  revision 2013-07-15 {
+    description
+     "This revision adds the following new data types:
+      - ip-address-no-zone
+      - ipv4-address-no-zone
+      - ipv6-address-no-zone";
+    reference
+     "RFC 6991: Common YANG Data Types";
+  }
+
+  revision 2010-09-24 {
+    description
+     "Initial revision.";
+    reference
+     "RFC 6021: Common YANG Data Types";
+  }
+
+  /*** collection of types related to protocol fields ***/
+
+  typedef ip-version {
+    type enumeration {
+      enum unknown {
+        value "0";
+        description
+         "An unknown or unspecified version of the Internet
+          protocol.";
+      }
+      enum ipv4 {
+        value "1";
+        description
+         "The IPv4 protocol as defined in RFC 791.";
+      }
+      enum ipv6 {
+        value "2";
+        description
+         "The IPv6 protocol as defined in RFC 2460.";
+      }
+    }
+    description
+     "This value represents the version of the IP protocol.
+
+      In the value set and its semantics, this type is equivalent
+      to the InetVersion textual convention of the SMIv2.";
+    reference
+     "RFC  791: Internet Protocol
+      RFC 2460: Internet Protocol, Version 6 (IPv6) Specification
+      RFC 4001: Textual Conventions for Internet Network Addresses";
+  }
+
+  typedef dscp {
+    type uint8 {
+      range "0..63";
+    }
+    description
+     "The dscp type represents a Differentiated Services Code Point
+      that may be used for marking packets in a traffic stream.
+      In the value set and its semantics, this type is equivalent
+      to the Dscp textual convention of the SMIv2.";
+    reference
+     "RFC 3289: Management Information Base for the Differentiated
+                Services Architecture
+      RFC 2474: Definition of the Differentiated Services Field
+                (DS Field) in the IPv4 and IPv6 Headers
+      RFC 2780: IANA Allocation Guidelines For Values In
+                the Internet Protocol and Related Headers";
+  }
+
+  typedef ipv6-flow-label {
+    type uint32 {
+      range "0..1048575";
+    }
+    description
+     "The ipv6-flow-label type represents the flow identifier or Flow
+      Label in an IPv6 packet header that may be used to
+      discriminate traffic flows.
+
+      In the value set and its semantics, this type is equivalent
+      to the IPv6FlowLabel textual convention of the SMIv2.";
+    reference
+     "RFC 3595: Textual Conventions for IPv6 Flow Label
+      RFC 2460: Internet Protocol, Version 6 (IPv6) Specification";
+  }
+
+  typedef port-number {
+    type uint16 {
+      range "0..65535";
+    }
+    description
+     "The port-number type represents a 16-bit port number of an
+      Internet transport-layer protocol such as UDP, TCP, DCCP, or
+      SCTP.  Port numbers are assigned by IANA.  A current list of
+      all assignments is available from <http://www.iana.org/>.
+
+      Note that the port number value zero is reserved by IANA.  In
+      situations where the value zero does not make sense, it can
+      be excluded by subtyping the port-number type.
+      In the value set and its semantics, this type is equivalent
+      to the InetPortNumber textual convention of the SMIv2.";
+    reference
+     "RFC  768: User Datagram Protocol
+      RFC  793: Transmission Control Protocol
+      RFC 4960: Stream Control Transmission Protocol
+      RFC 4340: Datagram Congestion Control Protocol (DCCP)
+      RFC 4001: Textual Conventions for Internet Network Addresses";
+  }
+
+  /*** collection of types related to autonomous systems ***/
+
+  typedef as-number {
+    type uint32;
+    description
+     "The as-number type represents autonomous system numbers
+      which identify an Autonomous System (AS).  An AS is a set
+      of routers under a single technical administration, using
+      an interior gateway protocol and common metrics to route
+      packets within the AS, and using an exterior gateway
+      protocol to route packets to other ASes.  IANA maintains
+      the AS number space and has delegated large parts to the
+      regional registries.
+
+      Autonomous system numbers were originally limited to 16
+      bits.  BGP extensions have enlarged the autonomous system
+      number space to 32 bits.  This type therefore uses an uint32
+      base type without a range restriction in order to support
+      a larger autonomous system number space.
+
+      In the value set and its semantics, this type is equivalent
+      to the InetAutonomousSystemNumber textual convention of
+      the SMIv2.";
+    reference
+     "RFC 1930: Guidelines for creation, selection, and registration
+                of an Autonomous System (AS)
+      RFC 4271: A Border Gateway Protocol 4 (BGP-4)
+      RFC 4001: Textual Conventions for Internet Network Addresses
+      RFC 6793: BGP Support for Four-Octet Autonomous System (AS)
+                Number Space";
+  }
+
+  /*** collection of types related to IP addresses and hostnames ***/
+
+  typedef ip-address {
+    type union {
+      type inet:ipv4-address;
+      type inet:ipv6-address;
+    }
+    description
+     "The ip-address type represents an IP address and is IP
+      version neutral.  The format of the textual representation
+      implies the IP version.  This type supports scoped addresses
+      by allowing zone identifiers in the address format.";
+    reference
+     "RFC 4007: IPv6 Scoped Address Architecture";
+  }
+
+  typedef ipv4-address {
+    type string {
+      pattern
+        '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
+      +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
+      + '(%[\p{N}\p{L}]+)?';
+    }
+    description
+      "The ipv4-address type represents an IPv4 address in
+       dotted-quad notation.  The IPv4 address may include a zone
+       index, separated by a % sign.
+
+       The zone index is used to disambiguate identical address
+       values.  For link-local addresses, the zone index will
+       typically be the interface index number or the name of an
+       interface.  If the zone index is not present, the default
+       zone of the device will be used.
+
+       The canonical format for the zone index is the numerical
+       format";
+  }
+
+  typedef ipv6-address {
+    type string {
+      pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
+            + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
+            + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
+            + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
+            + '(%[\p{N}\p{L}]+)?';
+      pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
+            + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
+            + '(%.+)?';
+    }
+    description
+     "The ipv6-address type represents an IPv6 address in full,
+      mixed, shortened, and shortened-mixed notation.  The IPv6
+      address may include a zone index, separated by a % sign.
+
+      The zone index is used to disambiguate identical address
+      values.  For link-local addresses, the zone index will
+      typically be the interface index number or the name of an
+      interface.  If the zone index is not present, the default
+      zone of the device will be used.
+
+      The canonical format of IPv6 addresses uses the textual
+      representation defined in Section 4 of RFC 5952.  The
+      canonical format for the zone index is the numerical
+      format as described in Section 11.2 of RFC 4007.";
+    reference
+     "RFC 4291: IP Version 6 Addressing Architecture
+      RFC 4007: IPv6 Scoped Address Architecture
+      RFC 5952: A Recommendation for IPv6 Address Text
+                Representation";
+  }
+
+  typedef ip-address-no-zone {
+    type union {
+      type inet:ipv4-address-no-zone;
+      type inet:ipv6-address-no-zone;
+    }
+    description
+     "The ip-address-no-zone type represents an IP address and is
+      IP version neutral.  The format of the textual representation
+      implies the IP version.  This type does not support scoped
+      addresses since it does not allow zone identifiers in the
+      address format.";
+    reference
+     "RFC 4007: IPv6 Scoped Address Architecture";
+  }
+
+  typedef ipv4-address-no-zone {
+    type inet:ipv4-address {
+      pattern '[0-9\.]*';
+    }
+    description
+      "An IPv4 address without a zone index.  This type, derived from
+       ipv4-address, may be used in situations where the zone is
+       known from the context and hence no zone index is needed.";
+  }
+
+  typedef ipv6-address-no-zone {
+    type inet:ipv6-address {
+      pattern '[0-9a-fA-F:\.]*';
+    }
+    description
+      "An IPv6 address without a zone index.  This type, derived from
+       ipv6-address, may be used in situations where the zone is
+       known from the context and hence no zone index is needed.";
+    reference
+     "RFC 4291: IP Version 6 Addressing Architecture
+      RFC 4007: IPv6 Scoped Address Architecture
+      RFC 5952: A Recommendation for IPv6 Address Text
+                Representation";
+  }
+
+  typedef ip-prefix {
+    type union {
+      type inet:ipv4-prefix;
+      type inet:ipv6-prefix;
+    }
+    description
+     "The ip-prefix type represents an IP prefix and is IP
+      version neutral.  The format of the textual representations
+      implies the IP version.";
+  }
+
+  typedef ipv4-prefix {
+    type string {
+      pattern
+         '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
+       +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
+       + '/(([0-9])|([1-2][0-9])|(3[0-2]))';
+    }
+    description
+     "The ipv4-prefix type represents an IPv4 address prefix.
+      The prefix length is given by the number following the
+      slash character and must be less than or equal to 32.
+
+      A prefix length value of n corresponds to an IP address
+      mask that has n contiguous 1-bits from the most
+      significant bit (MSB) and all other bits set to 0.
+
+      The canonical format of an IPv4 prefix has all bits of
+      the IPv4 address set to zero that are not part of the
+      IPv4 prefix.";
+  }
+
+  typedef ipv6-prefix {
+    type string {
+      pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
+            + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
+            + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
+            + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
+            + '(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))';
+      pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
+            + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
+            + '(/.+)';
+    }
+
+    description
+     "The ipv6-prefix type represents an IPv6 address prefix.
+      The prefix length is given by the number following the
+      slash character and must be less than or equal to 128.
+
+      A prefix length value of n corresponds to an IP address
+      mask that has n contiguous 1-bits from the most
+      significant bit (MSB) and all other bits set to 0.
+
+      The IPv6 address should have all bits that do not belong
+      to the prefix set to zero.
+
+      The canonical format of an IPv6 prefix has all bits of
+      the IPv6 address set to zero that are not part of the
+      IPv6 prefix.  Furthermore, the IPv6 address is represented
+      as defined in Section 4 of RFC 5952.";
+    reference
+     "RFC 5952: A Recommendation for IPv6 Address Text
+                Representation";
+  }
+
+  /*** collection of domain name and URI types ***/
+
+  typedef domain-name {
+    type string {
+      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]\.?)'
+      + '|\.';
+      length "1..253";
+    }
+    description
+     "The domain-name type represents a DNS domain name.  The
+      name SHOULD be fully qualified whenever possible.
+
+      Internet domain names are only loosely specified.  Section
+      3.5 of RFC 1034 recommends a syntax (modified in Section
+      2.1 of RFC 1123).  The pattern above is intended to allow
+      for current practice in domain name use, and some possible
+      future expansion.  It is designed to hold various types of
+      domain names, including names used for A or AAAA records
+      (host names) and other records, such as SRV records.  Note
+      that Internet host names have a stricter syntax (described
+      in RFC 952) than the DNS recommendations in RFCs 1034 and
+      1123, and that systems that want to store host names in
+      schema nodes using the domain-name type are recommended to
+      adhere to this stricter standard to ensure interoperability.
+
+      The encoding of DNS names in the DNS protocol is limited
+      to 255 characters.  Since the encoding consists of labels
+      prefixed by a length bytes and there is a trailing NULL
+      byte, only 253 characters can appear in the textual dotted
+      notation.
+
+      The description clause of schema nodes using the domain-name
+      type MUST describe when and how these names are resolved to
+      IP addresses.  Note that the resolution of a domain-name value
+      may require to query multiple DNS records (e.g., A for IPv4
+      and AAAA for IPv6).  The order of the resolution process and
+      which DNS record takes precedence can either be defined
+      explicitly or may depend on the configuration of the
+      resolver.
+
+      Domain-name values use the US-ASCII encoding.  Their canonical
+      format uses lowercase US-ASCII characters.  Internationalized
+      domain names MUST be A-labels as per RFC 5890.";
+    reference
+     "RFC  952: DoD Internet Host Table Specification
+      RFC 1034: Domain Names - Concepts and Facilities
+      RFC 1123: Requirements for Internet Hosts -- Application
+                and Support
+      RFC 2782: A DNS RR for specifying the location of services
+                (DNS SRV)
+      RFC 5890: Internationalized Domain Names in Applications
+                (IDNA): Definitions and Document Framework";
+  }
+
+  typedef host {
+    type union {
+      type inet:ip-address;
+      type inet:domain-name;
+    }
+    description
+     "The host type represents either an IP address or a DNS
+      domain name.";
+  }
+
+  typedef uri {
+    type string;
+    description
+     "The uri type represents a Uniform Resource Identifier
+      (URI) as defined by STD 66.
+
+      Objects using the uri type MUST be in US-ASCII encoding,
+      and MUST be normalized as described by RFC 3986 Sections
+      6.2.1, 6.2.2.1, and 6.2.2.2.  All unnecessary
+      percent-encoding is removed, and all case-insensitive
+      characters are set to lowercase except for hexadecimal
+      digits, which are normalized to uppercase as described in
+      Section 6.2.2.1.
+
+      The purpose of this normalization is to help provide
+      unique URIs.  Note that this normalization is not
+      sufficient to provide uniqueness.  Two URIs that are
+      textually distinct after this normalization may still be
+      equivalent.
+
+      Objects using the uri type may restrict the schemes that
+      they permit.  For example, 'data:' and 'urn:' schemes
+      might not be appropriate.
+
+      A zero-length URI is not a valid URI.  This can be used to
+      express 'URI absent' where required.
+
+      In the value set and its semantics, this type is equivalent
+      to the Uri SMIv2 textual convention defined in RFC 5017.";
+    reference
+     "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
+      RFC 3305: Report from the Joint W3C/IETF URI Planning Interest
+                Group: Uniform Resource Identifiers (URIs), URLs,
+                and Uniform Resource Names (URNs): Clarifications
+                and Recommendations
+      RFC 5017: MIB Textual Conventions for Uniform Resource
+                Identifiers (URIs)";
+  }
+
+}
diff --git a/cps-service/src/test/resources/ietf/ietf-network-state@2018-02-26.yang b/cps-service/src/test/resources/ietf/ietf-network-state@2018-02-26.yang
new file mode 100644
index 0000000000..9a6893da20
--- /dev/null
+++ b/cps-service/src/test/resources/ietf/ietf-network-state@2018-02-26.yang
@@ -0,0 +1,176 @@
+module ietf-network-state {
+  yang-version 1.1;
+  namespace "urn:ietf:params:xml:ns:yang:ietf-network-state";
+  prefix nw-s;
+
+  import ietf-network {
+    prefix nw;
+    reference
+      "RFC 8345: A YANG Data Model for Network Topologies";
+  }
+
+  organization
+    "IETF I2RS (Interface to the Routing System) Working Group";
+
+  contact
+    "WG Web:    <https://datatracker.ietf.org/wg/i2rs/>
+     WG List:   <mailto:i2rs@ietf.org>
+
+     Editor:    Alexander Clemm
+                <mailto:ludwig@clemm.org>
+
+     Editor:    Jan Medved
+                <mailto:jmedved@cisco.com>
+
+     Editor:    Robert Varga
+                <mailto:robert.varga@pantheon.tech>
+
+     Editor:    Nitin Bahadur
+                <mailto:nitin_bahadur@yahoo.com>
+     Editor:    Hariharan Ananthakrishnan
+                <mailto:hari@packetdesign.com>
+
+     Editor:    Xufeng Liu
+                <mailto:xufeng.liu.ietf@gmail.com>";
+
+  description
+    "This module defines a common base data model for a collection
+     of nodes in a network.  Node definitions are further used
+     in network topologies and inventories.  It represents
+     information that either (1) is learned and automatically
+     populated or (2) results from applying network information
+     that has been configured per the 'ietf-network' data model,
+     mirroring the corresponding data nodes in this data model.
+
+     The data model mirrors 'ietf-network' but contains only
+     read-only state data.  The data model is not needed when the
+     underlying implementation infrastructure supports the Network
+     Management Datastore Architecture (NMDA).
+
+     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).
+
+     This version of this YANG module is part of RFC 8345;
+     see the RFC itself for full legal notices.";
+
+  revision 2018-02-26 {
+    description
+      "Initial revision.";
+    reference
+      "RFC 8345: A YANG Data Model for Network Topologies";
+  }
+
+  grouping network-ref {
+    description
+      "Contains the information necessary to reference a network --
+       for example, an underlay network.";
+    leaf network-ref {
+      type leafref {
+        path "/nw-s:networks/nw-s:network/nw-s:network-id";
+      require-instance false;
+      }
+      description
+        "Used to reference a network -- for example, an underlay
+         network.";
+    }
+  }
+
+  grouping node-ref {
+    description
+      "Contains the information necessary to reference a node.";
+    leaf node-ref {
+      type leafref {
+        path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
+          "/../network-ref]/nw-s:node/nw-s:node-id";
+        require-instance false;
+      }
+      description
+        "Used to reference a node.
+         Nodes are identified relative to the network that
+         contains them.";
+    }
+    uses network-ref;
+  }
+
+  container networks {
+    config false;
+    description
+      "Serves as a top-level container for a list of networks.";
+    list network {
+      key "network-id";
+      description
+        "Describes a network.
+         A network typically contains an inventory of nodes,
+         topological information (augmented through the
+         network-topology data model), and layering information.";
+      container network-types {
+        description
+          "Serves as an augmentation target.
+           The network type is indicated through corresponding
+           presence containers augmented into this container.";
+      }
+      leaf network-id {
+        type nw:network-id;
+        description
+          "Identifies a network.";
+      }
+      list supporting-network {
+        key "network-ref";
+        description
+          "An underlay network, used to represent layered network
+           topologies.";
+        leaf network-ref {
+          type leafref {
+            path "/nw-s:networks/nw-s:network/nw-s:network-id";
+          require-instance false;
+          }
+          description
+            "References the underlay network.";
+        }
+      }
+
+      list node {
+        key "node-id";
+        description
+          "The inventory of nodes of this network.";
+        leaf node-id {
+          type nw:node-id;
+          description
+            "Uniquely identifies a node within the containing
+             network.";
+        }
+        list supporting-node {
+          key "network-ref node-ref";
+          description
+            "Represents another node that is in an underlay network
+             and that supports this node.  Used to represent layering
+             structure.";
+          leaf network-ref {
+            type leafref {
+              path "../../../nw-s:supporting-network/nw-s:network-ref";
+            require-instance false;
+            }
+            description
+              "References the underlay network of which the
+               underlay node is a part.";
+          }
+          leaf node-ref {
+            type leafref {
+              path "/nw-s:networks/nw-s:network/nw-s:node/nw-s:node-id";
+            require-instance false;
+            }
+            description
+              "References the underlay node itself.";
+          }
+        }
+      }
+    }
+  }
+}
diff --git a/cps-service/src/test/resources/ietf/ietf-network-topology-state@2018-02-26.yang b/cps-service/src/test/resources/ietf/ietf-network-topology-state@2018-02-26.yang
new file mode 100644
index 0000000000..1c1ba1b2e5
--- /dev/null
+++ b/cps-service/src/test/resources/ietf/ietf-network-topology-state@2018-02-26.yang
@@ -0,0 +1,273 @@
+module ietf-network-topology-state {
+  yang-version 1.1;
+  namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology-state";
+  prefix nt-s;
+
+  import ietf-network-state {
+    prefix nw-s;
+    reference
+      "RFC 8345: A YANG Data Model for Network Topologies";
+  }
+  import ietf-network-topology {
+    prefix nt;
+    reference
+      "RFC 8345: A YANG Data Model for Network Topologies";
+  }
+
+  organization
+    "IETF I2RS (Interface to the Routing System) Working Group";
+
+  contact
+    "WG Web:    <https://datatracker.ietf.org/wg/i2rs/>
+     WG List:   <mailto:i2rs@ietf.org>
+
+     Editor:    Alexander Clemm
+                <mailto:ludwig@clemm.org>
+
+     Editor:    Jan Medved
+                <mailto:jmedved@cisco.com>
+
+     Editor:    Robert Varga
+                <mailto:robert.varga@pantheon.tech>
+
+     Editor:    Nitin Bahadur
+                <mailto:nitin_bahadur@yahoo.com>
+
+     Editor:    Hariharan Ananthakrishnan
+                <mailto:hari@packetdesign.com>
+
+     Editor:    Xufeng Liu
+                <mailto:xufeng.liu.ietf@gmail.com>";
+
+  description
+    "This module defines a common base data model for network
+     topology state, representing topology that either (1) is learned
+     or (2) results from applying topology that has been configured
+     per the 'ietf-network-topology' data model, mirroring the
+     corresponding data nodes in this data model.  It augments the
+     base network state data model with links to connect nodes, as
+     well as termination points to terminate links on nodes.
+
+     The data model mirrors 'ietf-network-topology' but contains only
+     read-only state data.  The data model is not needed when the
+     underlying implementation infrastructure supports the Network
+     Management Datastore Architecture (NMDA).
+
+     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).
+
+     This version of this YANG module is part of RFC 8345;
+     see the RFC itself for full legal notices.";
+
+  revision 2018-02-26 {
+    description
+      "Initial revision.";
+    reference
+      "RFC 8345: A YANG Data Model for Network Topologies";
+  }
+
+  grouping link-ref {
+    description
+      "References a link in a specific network.  Although this
+       grouping is not used in this module, it is defined here for
+       the convenience of augmenting modules.";
+    leaf link-ref {
+      type leafref {
+        path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
+          "/../network-ref]/nt-s:link/nt-s:link-id";
+        require-instance false;
+      }
+      description
+        "A type for an absolute reference to a link instance.
+         (This type should not be used for relative references.
+         In such a case, a relative path should be used instead.)";
+    }
+    uses nw-s:network-ref;
+  }
+
+  grouping tp-ref {
+    description
+      "References a termination point in a specific node.  Although
+       this grouping is not used in this module, it is defined here
+       for the convenience of augmenting modules.";
+    leaf tp-ref {
+      type leafref {
+        path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+
+          "/../network-ref]/nw-s:node[nw-s:node-id=current()/../"+
+          "node-ref]/nt-s:termination-point/nt-s:tp-id";
+        require-instance false;
+      }
+      description
+        "A type for an absolute reference to a termination point.
+         (This type should not be used for relative references.
+         In such a case, a relative path should be used instead.)";
+    }
+    uses nw-s:node-ref;
+  }
+
+  augment "/nw-s:networks/nw-s:network" {
+    description
+      "Add links to the network data model.";
+    list link {
+      key "link-id";
+      description
+        "A network link connects a local (source) node and
+         a remote (destination) node via a set of the respective
+         node's termination points.  It is possible to have several
+         links between the same source and destination nodes.
+         Likewise, a link could potentially be re-homed between
+         termination points.  Therefore, in order to ensure that we
+         would always know to distinguish between links, every link
+         is identified by a dedicated link identifier.  Note that a
+         link models a point-to-point link, not a multipoint link.";
+      container source {
+        description
+          "This container holds the logical source of a particular
+           link.";
+        leaf source-node {
+          type leafref {
+            path "../../../nw-s:node/nw-s:node-id";
+            require-instance false;
+          }
+          description
+            "Source node identifier.  Must be in the same topology.";
+        }
+        leaf source-tp {
+          type leafref {
+            path "../../../nw-s:node[nw-s:node-id=current()/../"+
+              "source-node]/termination-point/tp-id";
+            require-instance false;
+          }
+          description
+            "This termination point is located within the source node
+             and terminates the link.";
+        }
+      }
+      container destination {
+        description
+          "This container holds the logical destination of a
+           particular link.";
+        leaf dest-node {
+          type leafref {
+            path "../../../nw-s:node/nw-s:node-id";
+          require-instance false;
+          }
+          description
+            "Destination node identifier.  Must be in the same
+             network.";
+        }
+
+        leaf dest-tp {
+          type leafref {
+            path "../../../nw-s:node[nw-s:node-id=current()/../"+
+              "dest-node]/termination-point/tp-id";
+            require-instance false;
+          }
+          description
+            "This termination point is located within the
+             destination node and terminates the link.";
+        }
+      }
+      leaf link-id {
+        type nt:link-id;
+        description
+          "The identifier of a link in the topology.
+           A link is specific to a topology to which it belongs.";
+      }
+      list supporting-link {
+        key "network-ref link-ref";
+        description
+          "Identifies the link or links on which this link depends.";
+        leaf network-ref {
+          type leafref {
+            path "../../../nw-s:supporting-network/nw-s:network-ref";
+          require-instance false;
+          }
+          description
+            "This leaf identifies in which underlay topology
+             the supporting link is present.";
+        }
+        leaf link-ref {
+          type leafref {
+            path "/nw-s:networks/nw-s:network[nw-s:network-id="+
+              "current()/../network-ref]/link/link-id";
+            require-instance false;
+          }
+          description
+            "This leaf identifies a link that is a part
+             of this link's underlay.  Reference loops in which
+             a link identifies itself as its underlay, either
+             directly or transitively, are not allowed.";
+        }
+      }
+    }
+  }
+
+  augment "/nw-s:networks/nw-s:network/nw-s:node" {
+    description
+      "Augments termination points that terminate links.
+       Termination points can ultimately be mapped to interfaces.";
+    list termination-point {
+      key "tp-id";
+      description
+        "A termination point can terminate a link.
+         Depending on the type of topology, a termination point
+         could, for example, refer to a port or an interface.";
+      leaf tp-id {
+        type nt:tp-id;
+        description
+          "Termination point identifier.";
+      }
+      list supporting-termination-point {
+        key "network-ref node-ref tp-ref";
+        description
+          "This list identifies any termination points on which a
+           given termination point depends or onto which it maps.
+           Those termination points will themselves be contained
+           in a supporting node.  This dependency information can be
+           inferred from the dependencies between links.  Therefore,
+           this item is not separately configurable.  Hence, no
+           corresponding constraint needs to be articulated.
+           The corresponding information is simply provided by the
+           implementing system.";
+        leaf network-ref {
+          type leafref {
+            path "../../../nw-s:supporting-node/nw-s:network-ref";
+          require-instance false;
+          }
+          description
+            "This leaf identifies in which topology the
+             supporting termination point is present.";
+        }
+        leaf node-ref {
+          type leafref {
+            path "../../../nw-s:supporting-node/nw-s:node-ref";
+          require-instance false;
+          }
+          description
+            "This leaf identifies in which node the supporting
+             termination point is present.";
+        }
+
+        leaf tp-ref {
+          type leafref {
+            path "/nw-s:networks/nw-s:network[nw-s:network-id="+
+              "current()/../network-ref]/nw-s:node[nw-s:node-id="+
+              "current()/../node-ref]/termination-point/tp-id";
+            require-instance false;
+          }
+          description
+            "Reference to the underlay node (the underlay node must
+             be in a different topology).";
+        }
+      }
+    }
+  }
+}
diff --git a/cps-service/src/test/resources/ietf/ietf-network-topology@2018-02-26.yang b/cps-service/src/test/resources/ietf/ietf-network-topology@2018-02-26.yang
new file mode 100644
index 0000000000..1ec944d791
--- /dev/null
+++ b/cps-service/src/test/resources/ietf/ietf-network-topology@2018-02-26.yang
@@ -0,0 +1,294 @@
+module ietf-network-topology {
+  yang-version 1.1;
+  namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology";
+  prefix nt;
+
+  import ietf-inet-types {
+    prefix inet;
+    reference
+      "RFC 6991: Common YANG Data Types";
+  }
+  import ietf-network {
+    prefix nw;
+    reference
+      "RFC 8345: A YANG Data Model for Network Topologies";
+  }
+
+  organization
+    "IETF I2RS (Interface to the Routing System) Working Group";
+
+  contact
+    "WG Web:    <https://datatracker.ietf.org/wg/i2rs/>
+     WG List:   <mailto:i2rs@ietf.org>
+
+     Editor:    Alexander Clemm
+                <mailto:ludwig@clemm.org>
+
+     Editor:    Jan Medved
+                <mailto:jmedved@cisco.com>
+
+     Editor:    Robert Varga
+                <mailto:robert.varga@pantheon.tech>
+
+     Editor:    Nitin Bahadur
+                <mailto:nitin_bahadur@yahoo.com>
+
+     Editor:    Hariharan Ananthakrishnan
+                <mailto:hari@packetdesign.com>
+
+     Editor:    Xufeng Liu
+                <mailto:xufeng.liu.ietf@gmail.com>";
+
+  description
+    "This module defines a common base model for a network topology,
+     augmenting the base network data model with links to connect
+     nodes, as well as termination points to terminate links
+     on nodes.
+
+     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).
+
+     This version of this YANG module is part of RFC 8345;
+     see the RFC itself for full legal notices.";
+
+  revision 2018-02-26 {
+    description
+      "Initial revision.";
+    reference
+      "RFC 8345: A YANG Data Model for Network Topologies";
+  }
+
+  typedef link-id {
+    type inet:uri;
+    description
+      "An identifier for a link in a topology.  The precise
+       structure of the link-id will be up to the implementation.
+       The identifier SHOULD be chosen such that the same link in a
+       real network topology will always be identified through the
+       same identifier, even if the data model is instantiated in
+       separate datastores.  An implementation MAY choose to capture
+       semantics in the identifier -- for example, to indicate the
+       type of link and/or the type of topology of which the link is
+       a part.";
+  }
+
+  typedef tp-id {
+    type inet:uri;
+    description
+      "An identifier for termination points on a node.  The precise
+       structure of the tp-id will be up to the implementation.
+       The identifier SHOULD be chosen such that the same termination
+       point in a real network topology will always be identified
+       through the same identifier, even if the data model is
+       instantiated in separate datastores.  An implementation MAY
+       choose to capture semantics in the identifier -- for example,
+       to indicate the type of termination point and/or the type of
+       node that contains the termination point.";
+  }
+
+  grouping link-ref {
+    description
+      "This grouping can be used to reference a link in a specific
+       network.  Although it is not used in this module, it is
+       defined here for the convenience of augmenting modules.";
+    leaf link-ref {
+      type leafref {
+        path "/nw:networks/nw:network[nw:network-id=current()/../"+
+          "network-ref]/nt:link/nt:link-id";
+        require-instance false;
+      }
+      description
+        "A type for an absolute reference to a link instance.
+         (This type should not be used for relative references.
+         In such a case, a relative path should be used instead.)";
+    }
+    uses nw:network-ref;
+  }
+
+  grouping tp-ref {
+    description
+      "This grouping can be used to reference a termination point
+       in a specific node.  Although it is not used in this module,
+       it is defined here for the convenience of augmenting
+       modules.";
+    leaf tp-ref {
+      type leafref {
+        path "/nw:networks/nw:network[nw:network-id=current()/../"+
+          "network-ref]/nw:node[nw:node-id=current()/../"+
+          "node-ref]/nt:termination-point/nt:tp-id";
+        require-instance false;
+      }
+      description
+        "A type for an absolute reference to a termination point.
+         (This type should not be used for relative references.
+         In such a case, a relative path should be used instead.)";
+    }
+    uses nw:node-ref;
+  }
+
+  augment "/nw:networks/nw:network" {
+    description
+      "Add links to the network data model.";
+    list link {
+      key "link-id";
+      description
+        "A network link connects a local (source) node and
+         a remote (destination) node via a set of the respective
+         node's termination points.  It is possible to have several
+         links between the same source and destination nodes.
+         Likewise, a link could potentially be re-homed between
+         termination points.  Therefore, in order to ensure that we
+         would always know to distinguish between links, every link
+         is identified by a dedicated link identifier.  Note that a
+         link models a point-to-point link, not a multipoint link.";
+      leaf link-id {
+        type link-id;
+        description
+          "The identifier of a link in the topology.
+           A link is specific to a topology to which it belongs.";
+      }
+      container source {
+        description
+          "This container holds the logical source of a particular
+           link.";
+        leaf source-node {
+          type leafref {
+            path "../../../nw:node/nw:node-id";
+            require-instance false;
+          }
+          description
+            "Source node identifier.  Must be in the same topology.";
+        }
+        leaf source-tp {
+          type leafref {
+            path "../../../nw:node[nw:node-id=current()/../"+
+              "source-node]/termination-point/tp-id";
+            require-instance false;
+          }
+          description
+            "This termination point is located within the source node
+             and terminates the link.";
+        }
+      }
+
+      container destination {
+        description
+          "This container holds the logical destination of a
+           particular link.";
+        leaf dest-node {
+          type leafref {
+            path "../../../nw:node/nw:node-id";
+          require-instance false;
+          }
+          description
+            "Destination node identifier.  Must be in the same
+             network.";
+        }
+        leaf dest-tp {
+          type leafref {
+            path "../../../nw:node[nw:node-id=current()/../"+
+              "dest-node]/termination-point/tp-id";
+            require-instance false;
+          }
+          description
+            "This termination point is located within the
+             destination node and terminates the link.";
+        }
+      }
+      list supporting-link {
+        key "network-ref link-ref";
+        description
+          "Identifies the link or links on which this link depends.";
+        leaf network-ref {
+          type leafref {
+            path "../../../nw:supporting-network/nw:network-ref";
+          require-instance false;
+          }
+          description
+            "This leaf identifies in which underlay topology
+             the supporting link is present.";
+        }
+
+        leaf link-ref {
+          type leafref {
+            path "/nw:networks/nw:network[nw:network-id=current()/"+
+              "../network-ref]/link/link-id";
+            require-instance false;
+          }
+          description
+            "This leaf identifies a link that is a part
+             of this link's underlay.  Reference loops in which
+             a link identifies itself as its underlay, either
+             directly or transitively, are not allowed.";
+        }
+      }
+    }
+  }
+  augment "/nw:networks/nw:network/nw:node" {
+    description
+      "Augments termination points that terminate links.
+       Termination points can ultimately be mapped to interfaces.";
+    list termination-point {
+      key "tp-id";
+      description
+        "A termination point can terminate a link.
+         Depending on the type of topology, a termination point
+         could, for example, refer to a port or an interface.";
+      leaf tp-id {
+        type tp-id;
+        description
+          "Termination point identifier.";
+      }
+      list supporting-termination-point {
+        key "network-ref node-ref tp-ref";
+        description
+          "This list identifies any termination points on which a
+           given termination point depends or onto which it maps.
+           Those termination points will themselves be contained
+           in a supporting node.  This dependency information can be
+           inferred from the dependencies between links.  Therefore,
+           this item is not separately configurable.  Hence, no
+           corresponding constraint needs to be articulated.
+           The corresponding information is simply provided by the
+           implementing system.";
+
+        leaf network-ref {
+          type leafref {
+            path "../../../nw:supporting-node/nw:network-ref";
+          require-instance false;
+          }
+          description
+            "This leaf identifies in which topology the
+             supporting termination point is present.";
+        }
+        leaf node-ref {
+          type leafref {
+            path "../../../nw:supporting-node/nw:node-ref";
+          require-instance false;
+          }
+          description
+            "This leaf identifies in which node the supporting
+             termination point is present.";
+        }
+        leaf tp-ref {
+          type leafref {
+            path "/nw:networks/nw:network[nw:network-id=current()/"+
+              "../network-ref]/nw:node[nw:node-id=current()/../"+
+              "node-ref]/termination-point/tp-id";
+            require-instance false;
+          }
+          description
+            "Reference to the underlay node (the underlay node must
+             be in a different topology).";
+        }
+      }
+    }
+  }
+}
diff --git a/cps-service/src/test/resources/ietf/ietf-network@2018-02-26.yang b/cps-service/src/test/resources/ietf/ietf-network@2018-02-26.yang
new file mode 100644
index 0000000000..6a03d7e416
--- /dev/null
+++ b/cps-service/src/test/resources/ietf/ietf-network@2018-02-26.yang
@@ -0,0 +1,192 @@
+module ietf-network {
+  yang-version 1.1;
+  namespace "urn:ietf:params:xml:ns:yang:ietf-network";
+  prefix nw;
+
+  import ietf-inet-types {
+    prefix inet;
+    reference
+      "RFC 6991: Common YANG Data Types";
+  }
+
+  organization
+    "IETF I2RS (Interface to the Routing System) Working Group";
+
+  contact
+    "WG Web:    <https://datatracker.ietf.org/wg/i2rs/>
+     WG List:   <mailto:i2rs@ietf.org>
+
+     Editor:    Alexander Clemm
+                <mailto:ludwig@clemm.org>
+
+     Editor:    Jan Medved
+                <mailto:jmedved@cisco.com>
+
+     Editor:    Robert Varga
+                <mailto:robert.varga@pantheon.tech>
+
+     Editor:    Nitin Bahadur
+                <mailto:nitin_bahadur@yahoo.com>
+
+     Editor:    Hariharan Ananthakrishnan
+                <mailto:hari@packetdesign.com>
+
+     Editor:    Xufeng Liu
+                <mailto:xufeng.liu.ietf@gmail.com>";
+  description
+    "This module defines a common base data model for a collection
+     of nodes in a network.  Node definitions are further used
+     in network topologies and inventories.
+
+     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).
+
+     This version of this YANG module is part of RFC 8345;
+     see the RFC itself for full legal notices.";
+
+  revision 2018-02-26 {
+    description
+      "Initial revision.";
+    reference
+      "RFC 8345: A YANG Data Model for Network Topologies";
+  }
+
+  typedef node-id {
+    type inet:uri;
+    description
+      "Identifier for a node.  The precise structure of the node-id
+       will be up to the implementation.  For example, some
+       implementations MAY pick a URI that includes the network-id
+       as part of the path.  The identifier SHOULD be chosen
+       such that the same node in a real network topology will
+       always be identified through the same identifier, even if
+       the data model is instantiated in separate datastores.  An
+       implementation MAY choose to capture semantics in the
+       identifier -- for example, to indicate the type of node.";
+  }
+
+  typedef network-id {
+    type inet:uri;
+    description
+      "Identifier for a network.  The precise structure of the
+       network-id will be up to the implementation.  The identifier
+       SHOULD be chosen such that the same network will always be
+       identified through the same identifier, even if the data model
+       is instantiated in separate datastores.  An implementation MAY
+       choose to capture semantics in the identifier -- for example,
+       to indicate the type of network.";
+  }
+
+  grouping network-ref {
+    description
+      "Contains the information necessary to reference a network --
+       for example, an underlay network.";
+    leaf network-ref {
+      type leafref {
+        path "/nw:networks/nw:network/nw:network-id";
+      require-instance false;
+      }
+      description
+        "Used to reference a network -- for example, an underlay
+         network.";
+    }
+  }
+
+  grouping node-ref {
+    description
+      "Contains the information necessary to reference a node.";
+    leaf node-ref {
+      type leafref {
+        path "/nw:networks/nw:network[nw:network-id=current()/../"+
+          "network-ref]/nw:node/nw:node-id";
+        require-instance false;
+      }
+      description
+        "Used to reference a node.
+         Nodes are identified relative to the network that
+         contains them.";
+    }
+    uses network-ref;
+  }
+
+  container networks {
+    description
+      "Serves as a top-level container for a list of networks.";
+    list network {
+      key "network-id";
+      description
+        "Describes a network.
+         A network typically contains an inventory of nodes,
+         topological information (augmented through the
+         network-topology data model), and layering information.";
+      leaf network-id {
+        type network-id;
+        description
+          "Identifies a network.";
+      }
+      container network-types {
+        description
+          "Serves as an augmentation target.
+           The network type is indicated through corresponding
+           presence containers augmented into this container.";
+      }
+      list supporting-network {
+        key "network-ref";
+        description
+          "An underlay network, used to represent layered network
+           topologies.";
+        leaf network-ref {
+          type leafref {
+            path "/nw:networks/nw:network/nw:network-id";
+          require-instance false;
+          }
+          description
+            "References the underlay network.";
+        }
+      }
+
+      list node {
+        key "node-id";
+        description
+          "The inventory of nodes of this network.";
+        leaf node-id {
+          type node-id;
+          description
+            "Uniquely identifies a node within the containing
+             network.";
+        }
+        list supporting-node {
+          key "network-ref node-ref";
+          description
+            "Represents another node that is in an underlay network
+             and that supports this node.  Used to represent layering
+             structure.";
+          leaf network-ref {
+            type leafref {
+              path "../../../nw:supporting-network/nw:network-ref";
+            require-instance false;
+            }
+            description
+              "References the underlay network of which the
+               underlay node is a part.";
+          }
+          leaf node-ref {
+            type leafref {
+              path "/nw:networks/nw:network/nw:node/nw:node-id";
+            require-instance false;
+            }
+            description
+              "References the underlay node itself.";
+          }
+        }
+      }
+    }
+  }
+}
diff --git a/cps-service/src/test/resources/ietf/ietf-yang-types@2013-07-15.yang b/cps-service/src/test/resources/ietf/ietf-yang-types@2013-07-15.yang
new file mode 100644
index 0000000000..ee58fa3ab0
--- /dev/null
+++ b/cps-service/src/test/resources/ietf/ietf-yang-types@2013-07-15.yang
@@ -0,0 +1,474 @@
+module ietf-yang-types {
+
+  namespace "urn:ietf:params:xml:ns:yang:ietf-yang-types";
+  prefix "yang";
+
+  organization
+   "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
+
+  contact
+   "WG Web:   <http://tools.ietf.org/wg/netmod/>
+    WG List:  <mailto:netmod@ietf.org>
+
+    WG Chair: David Kessens
+              <mailto:david.kessens@nsn.com>
+
+    WG Chair: Juergen Schoenwaelder
+              <mailto:j.schoenwaelder@jacobs-university.de>
+
+    Editor:   Juergen Schoenwaelder
+              <mailto:j.schoenwaelder@jacobs-university.de>";
+
+  description
+   "This module contains a collection of generally useful derived
+    YANG data types.
+
+    Copyright (c) 2013 IETF Trust and the persons identified as
+    authors of the code.  All rights reserved.
+
+    Redistribution and use in source and binary forms, with or
+    without modification, is permitted pursuant to, and subject
+    to the license terms contained in, the Simplified BSD License
+    set forth in Section 4.c of the IETF Trust's Legal Provisions
+    Relating to IETF Documents
+    (http://trustee.ietf.org/license-info).
+
+    This version of this YANG module is part of RFC 6991; see
+    the RFC itself for full legal notices.";
+
+  revision 2013-07-15 {
+    description
+     "This revision adds the following new data types:
+      - yang-identifier
+      - hex-string
+      - uuid
+      - dotted-quad";
+    reference
+     "RFC 6991: Common YANG Data Types";
+  }
+
+  revision 2010-09-24 {
+    description
+     "Initial revision.";
+    reference
+     "RFC 6021: Common YANG Data Types";
+  }
+
+  /*** collection of counter and gauge types ***/
+
+  typedef counter32 {
+    type uint32;
+    description
+     "The counter32 type represents a non-negative integer
+      that monotonically increases until it reaches a
+      maximum value of 2^32-1 (4294967295 decimal), when it
+      wraps around and starts increasing again from zero.
+
+      Counters have no defined 'initial' value, and thus, a
+      single value of a counter has (in general) no information
+      content.  Discontinuities in the monotonically increasing
+      value normally occur at re-initialization of the
+      management system, and at other times as specified in the
+      description of a schema node using this type.  If such
+      other times can occur, for example, the creation of
+      a schema node of type counter32 at times other than
+      re-initialization, then a corresponding schema node
+      should be defined, with an appropriate type, to indicate
+      the last discontinuity.
+
+      The counter32 type should not be used for configuration
+      schema nodes.  A default statement SHOULD NOT be used in
+      combination with the type counter32.
+
+      In the value set and its semantics, this type is equivalent
+      to the Counter32 type of the SMIv2.";
+    reference
+     "RFC 2578: Structure of Management Information Version 2
+                (SMIv2)";
+  }
+
+  typedef zero-based-counter32 {
+    type yang:counter32;
+    default "0";
+    description
+     "The zero-based-counter32 type represents a counter32
+      that has the defined 'initial' value zero.
+
+      A schema node of this type will be set to zero (0) on creation
+      and will thereafter increase monotonically until it reaches
+      a maximum value of 2^32-1 (4294967295 decimal), when it
+      wraps around and starts increasing again from zero.
+
+      Provided that an application discovers a new schema node
+      of this type within the minimum time to wrap, it can use the
+      'initial' value as a delta.  It is important for a management
+      station to be aware of this minimum time and the actual time
+      between polls, and to discard data if the actual time is too
+      long or there is no defined minimum time.
+
+      In the value set and its semantics, this type is equivalent
+      to the ZeroBasedCounter32 textual convention of the SMIv2.";
+    reference
+      "RFC 4502: Remote Network Monitoring Management Information
+                 Base Version 2";
+  }
+
+  typedef counter64 {
+    type uint64;
+    description
+     "The counter64 type represents a non-negative integer
+      that monotonically increases until it reaches a
+      maximum value of 2^64-1 (18446744073709551615 decimal),
+      when it wraps around and starts increasing again from zero.
+
+      Counters have no defined 'initial' value, and thus, a
+      single value of a counter has (in general) no information
+      content.  Discontinuities in the monotonically increasing
+      value normally occur at re-initialization of the
+      management system, and at other times as specified in the
+      description of a schema node using this type.  If such
+      other times can occur, for example, the creation of
+      a schema node of type counter64 at times other than
+      re-initialization, then a corresponding schema node
+      should be defined, with an appropriate type, to indicate
+      the last discontinuity.
+
+      The counter64 type should not be used for configuration
+      schema nodes.  A default statement SHOULD NOT be used in
+      combination with the type counter64.
+
+      In the value set and its semantics, this type is equivalent
+      to the Counter64 type of the SMIv2.";
+    reference
+     "RFC 2578: Structure of Management Information Version 2
+                (SMIv2)";
+  }
+
+  typedef zero-based-counter64 {
+    type yang:counter64;
+    default "0";
+    description
+     "The zero-based-counter64 type represents a counter64 that
+      has the defined 'initial' value zero.
+
+      A schema node of this type will be set to zero (0) on creation
+      and will thereafter increase monotonically until it reaches
+      a maximum value of 2^64-1 (18446744073709551615 decimal),
+      when it wraps around and starts increasing again from zero.
+
+      Provided that an application discovers a new schema node
+      of this type within the minimum time to wrap, it can use the
+      'initial' value as a delta.  It is important for a management
+      station to be aware of this minimum time and the actual time
+      between polls, and to discard data if the actual time is too
+      long or there is no defined minimum time.
+
+      In the value set and its semantics, this type is equivalent
+      to the ZeroBasedCounter64 textual convention of the SMIv2.";
+    reference
+     "RFC 2856: Textual Conventions for Additional High Capacity
+                Data Types";
+  }
+
+  typedef gauge32 {
+    type uint32;
+    description
+     "The gauge32 type represents a non-negative integer, which
+      may increase or decrease, but shall never exceed a maximum
+      value, nor fall below a minimum value.  The maximum value
+      cannot be greater than 2^32-1 (4294967295 decimal), and
+      the minimum value cannot be smaller than 0.  The value of
+      a gauge32 has its maximum value whenever the information
+      being modeled is greater than or equal to its maximum
+      value, and has its minimum value whenever the information
+      being modeled is smaller than or equal to its minimum value.
+      If the information being modeled subsequently decreases
+      below (increases above) the maximum (minimum) value, the
+      gauge32 also decreases (increases).
+
+      In the value set and its semantics, this type is equivalent
+      to the Gauge32 type of the SMIv2.";
+    reference
+     "RFC 2578: Structure of Management Information Version 2
+                (SMIv2)";
+  }
+
+  typedef gauge64 {
+    type uint64;
+    description
+     "The gauge64 type represents a non-negative integer, which
+      may increase or decrease, but shall never exceed a maximum
+      value, nor fall below a minimum value.  The maximum value
+      cannot be greater than 2^64-1 (18446744073709551615), and
+      the minimum value cannot be smaller than 0.  The value of
+      a gauge64 has its maximum value whenever the information
+      being modeled is greater than or equal to its maximum
+      value, and has its minimum value whenever the information
+      being modeled is smaller than or equal to its minimum value.
+      If the information being modeled subsequently decreases
+      below (increases above) the maximum (minimum) value, the
+      gauge64 also decreases (increases).
+
+      In the value set and its semantics, this type is equivalent
+      to the CounterBasedGauge64 SMIv2 textual convention defined
+      in RFC 2856";
+    reference
+     "RFC 2856: Textual Conventions for Additional High Capacity
+                Data Types";
+  }
+
+  /*** collection of identifier-related types ***/
+
+  typedef object-identifier {
+    type string {
+      pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))'
+            + '(\.(0|([1-9]\d*)))*';
+    }
+    description
+     "The object-identifier type represents administratively
+      assigned names in a registration-hierarchical-name tree.
+
+      Values of this type are denoted as a sequence of numerical
+      non-negative sub-identifier values.  Each sub-identifier
+      value MUST NOT exceed 2^32-1 (4294967295).  Sub-identifiers
+      are separated by single dots and without any intermediate
+      whitespace.
+
+      The ASN.1 standard restricts the value space of the first
+      sub-identifier to 0, 1, or 2.  Furthermore, the value space
+      of the second sub-identifier is restricted to the range
+      0 to 39 if the first sub-identifier is 0 or 1.  Finally,
+      the ASN.1 standard requires that an object identifier
+      has always at least two sub-identifiers.  The pattern
+      captures these restrictions.
+
+      Although the number of sub-identifiers is not limited,
+      module designers should realize that there may be
+      implementations that stick with the SMIv2 limit of 128
+      sub-identifiers.
+
+      This type is a superset of the SMIv2 OBJECT IDENTIFIER type
+      since it is not restricted to 128 sub-identifiers.  Hence,
+      this type SHOULD NOT be used to represent the SMIv2 OBJECT
+      IDENTIFIER type; the object-identifier-128 type SHOULD be
+      used instead.";
+    reference
+     "ISO9834-1: Information technology -- Open Systems
+      Interconnection -- Procedures for the operation of OSI
+      Registration Authorities: General procedures and top
+      arcs of the ASN.1 Object Identifier tree";
+  }
+
+  typedef object-identifier-128 {
+    type object-identifier {
+      pattern '\d*(\.\d*){1,127}';
+    }
+    description
+     "This type represents object-identifiers restricted to 128
+      sub-identifiers.
+
+      In the value set and its semantics, this type is equivalent
+      to the OBJECT IDENTIFIER type of the SMIv2.";
+    reference
+     "RFC 2578: Structure of Management Information Version 2
+                (SMIv2)";
+  }
+
+  typedef yang-identifier {
+    type string {
+      length "1..max";
+      pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
+      pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*';
+    }
+    description
+      "A YANG identifier string as defined by the 'identifier'
+       rule in Section 12 of RFC 6020.  An identifier must
+       start with an alphabetic character or an underscore
+       followed by an arbitrary sequence of alphabetic or
+       numeric characters, underscores, hyphens, or dots.
+
+       A YANG identifier MUST NOT start with any possible
+       combination of the lowercase or uppercase character
+       sequence 'xml'.";
+    reference
+      "RFC 6020: YANG - A Data Modeling Language for the Network
+                 Configuration Protocol (NETCONF)";
+  }
+
+  /*** collection of types related to date and time***/
+
+  typedef date-and-time {
+    type string {
+      pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.\d+)?'
+            + '(Z|[\+\-]\d{2}:\d{2})';
+    }
+    description
+     "The date-and-time type is a profile of the ISO 8601
+      standard for representation of dates and times using the
+      Gregorian calendar.  The profile is defined by the
+      date-time production in Section 5.6 of RFC 3339.
+
+      The date-and-time type is compatible with the dateTime XML
+      schema type with the following notable exceptions:
+
+      (a) The date-and-time type does not allow negative years.
+
+      (b) The date-and-time time-offset -00:00 indicates an unknown
+          time zone (see RFC 3339) while -00:00 and +00:00 and Z
+          all represent the same time zone in dateTime.
+
+      (c) The canonical format (see below) of data-and-time values
+          differs from the canonical format used by the dateTime XML
+          schema type, which requires all times to be in UTC using
+          the time-offset 'Z'.
+
+      This type is not equivalent to the DateAndTime textual
+      convention of the SMIv2 since RFC 3339 uses a different
+      separator between full-date and full-time and provides
+      higher resolution of time-secfrac.
+
+      The canonical format for date-and-time values with a known time
+      zone uses a numeric time zone offset that is calculated using
+      the device's configured known offset to UTC time.  A change of
+      the device's offset to UTC time will cause date-and-time values
+      to change accordingly.  Such changes might happen periodically
+      in case a server follows automatically daylight saving time
+      (DST) time zone offset changes.  The canonical format for
+      date-and-time values with an unknown time zone (usually
+      referring to the notion of local time) uses the time-offset
+      -00:00.";
+    reference
+     "RFC 3339: Date and Time on the Internet: Timestamps
+      RFC 2579: Textual Conventions for SMIv2
+      XSD-TYPES: XML Schema Part 2: Datatypes Second Edition";
+  }
+
+  typedef timeticks {
+    type uint32;
+    description
+     "The timeticks type represents a non-negative integer that
+      represents the time, modulo 2^32 (4294967296 decimal), in
+      hundredths of a second between two epochs.  When a schema
+      node is defined that uses this type, the description of
+      the schema node identifies both of the reference epochs.
+
+      In the value set and its semantics, this type is equivalent
+      to the TimeTicks type of the SMIv2.";
+    reference
+     "RFC 2578: Structure of Management Information Version 2
+                (SMIv2)";
+  }
+
+  typedef timestamp {
+    type yang:timeticks;
+    description
+     "The timestamp type represents the value of an associated
+      timeticks schema node at which a specific occurrence
+      happened.  The specific occurrence must be defined in the
+      description of any schema node defined using this type.  When
+      the specific occurrence occurred prior to the last time the
+      associated timeticks attribute was zero, then the timestamp
+      value is zero.  Note that this requires all timestamp values
+      to be reset to zero when the value of the associated timeticks
+      attribute reaches 497+ days and wraps around to zero.
+
+      The associated timeticks schema node must be specified
+      in the description of any schema node using this type.
+
+      In the value set and its semantics, this type is equivalent
+      to the TimeStamp textual convention of the SMIv2.";
+    reference
+     "RFC 2579: Textual Conventions for SMIv2";
+  }
+
+  /*** collection of generic address types ***/
+
+  typedef phys-address {
+    type string {
+      pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?';
+    }
+
+    description
+     "Represents media- or physical-level addresses represented
+      as a sequence octets, each octet represented by two hexadecimal
+      numbers.  Octets are separated by colons.  The canonical
+      representation uses lowercase characters.
+
+      In the value set and its semantics, this type is equivalent
+      to the PhysAddress textual convention of the SMIv2.";
+    reference
+     "RFC 2579: Textual Conventions for SMIv2";
+  }
+
+  typedef mac-address {
+    type string {
+      pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}';
+    }
+    description
+     "The mac-address type represents an IEEE 802 MAC address.
+      The canonical representation uses lowercase characters.
+
+      In the value set and its semantics, this type is equivalent
+      to the MacAddress textual convention of the SMIv2.";
+    reference
+     "IEEE 802: IEEE Standard for Local and Metropolitan Area
+                Networks: Overview and Architecture
+      RFC 2579: Textual Conventions for SMIv2";
+  }
+
+  /*** collection of XML-specific types ***/
+
+  typedef xpath1.0 {
+    type string;
+    description
+     "This type represents an XPATH 1.0 expression.
+
+      When a schema node is defined that uses this type, the
+      description of the schema node MUST specify the XPath
+      context in which the XPath expression is evaluated.";
+    reference
+     "XPATH: XML Path Language (XPath) Version 1.0";
+  }
+
+  /*** collection of string types ***/
+
+  typedef hex-string {
+    type string {
+      pattern '([0-9a-fA-F]{2}(:[0-9a-fA-F]{2})*)?';
+    }
+    description
+     "A hexadecimal string with octets represented as hex digits
+      separated by colons.  The canonical representation uses
+      lowercase characters.";
+  }
+
+  typedef uuid {
+    type string {
+      pattern '[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-'
+            + '[0-9a-fA-F]{4}-[0-9a-fA-F]{12}';
+    }
+    description
+     "A Universally Unique IDentifier in the string representation
+      defined in RFC 4122.  The canonical representation uses
+      lowercase characters.
+
+      The following is an example of a UUID in string representation:
+      f81d4fae-7dec-11d0-a765-00a0c91e6bf6
+      ";
+    reference
+     "RFC 4122: A Universally Unique IDentifier (UUID) URN
+                Namespace";
+  }
+
+  typedef dotted-quad {
+    type string {
+      pattern
+        '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
+      + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
+    }
+    description
+      "An unsigned 32-bit number expressed in the dotted-quad
+       notation, i.e., four octets written as decimal numbers
+       and separated with the '.' (full stop) character.";
+  }
+}