diff --git a/models/openconfig/BUCK b/models/openconfig/BUCK
index 60f7572..5905528 100644
--- a/models/openconfig/BUCK
+++ b/models/openconfig/BUCK
@@ -1,5 +1,10 @@
 COMPILE_DEPS = [
     '//lib:CORE_DEPS',
+    '//models/ietf:onos-models-ietf',
+]
+
+APPS = [
+    'org.onosproject.models.ietf',
 ]
 
 yang_model(
@@ -7,4 +12,5 @@
   title = 'OpenConfig YANG Models',
   custom_registrator = True,
   deps = COMPILE_DEPS,
+  required_apps = APPS,
 )
diff --git a/models/openconfig/pom.xml b/models/openconfig/pom.xml
index d81422b..cfa6354 100644
--- a/models/openconfig/pom.xml
+++ b/models/openconfig/pom.xml
@@ -47,6 +47,12 @@
             <version>${project.version}</version>
         </dependency>
 
+        <dependency>
+            <groupId>org.onosproject</groupId>
+            <artifactId>onos-models-ietf</artifactId>
+            <version>${project.version}</version>
+        </dependency>
+
     </dependencies>
 
     <build>
diff --git a/models/openconfig/src/main/yang/comm/ietf-inet-types@2013-07-15.yang b/models/openconfig/src/main/yang/comm/ietf-inet-types@2013-07-15.yang
deleted file mode 100644
index 2b7ed38..0000000
--- a/models/openconfig/src/main/yang/comm/ietf-inet-types@2013-07-15.yang
+++ /dev/null
@@ -1,454 +0,0 @@
-  module ietf-inet-types {
-
-    yang-version 1;
-
-    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";
-
-    }
-
-
-    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";
-
-    }
-
-    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";
-
-    }
-
-    typedef ip-address {
-      type union {
-        type ipv4-address;
-        type 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 ipv4-address-no-zone;
-        type 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 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 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 ipv4-prefix;
-        type 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";
-
-    }
-
-    typedef domain-name {
-      type string {
-        length "1..253";
-        pattern
-          '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)|\.';
-      }
-      description
-        "The domain-name type represents a DNS domain name.  The
-      name SHOULD be fully qualified whenever possible.
-
-      Internet domain names are only loosely specified.  Section
-      3.5 of RFC 1034 recommends a syntax (modified in Section
-      2.1 of RFC 1123).  The pattern above is intended to allow
-      for current practice in domain name use, and some possible
-      future expansion.  It is designed to hold various types of
-      domain names, including names used for A or AAAA records
-      (host names) and other records, such as SRV records.  Note
-      that Internet host names have a stricter syntax (described
-      in RFC 952) than the DNS recommendations in RFCs 1034 and
-      1123, and that systems that want to store host names in
-      schema nodes using the domain-name type are recommended to
-      adhere to this stricter standard to ensure interoperability.
-
-      The encoding of DNS names in the DNS protocol is limited
-      to 255 characters.  Since the encoding consists of labels
-      prefixed by a length bytes and there is a trailing NULL
-      byte, only 253 characters can appear in the textual dotted
-      notation.
-
-      The description clause of schema nodes using the domain-name
-      type MUST describe when and how these names are resolved to
-      IP addresses.  Note that the resolution of a domain-name value
-      may require to query multiple DNS records (e.g., A for IPv4
-      and AAAA for IPv6).  The order of the resolution process and
-      which DNS record takes precedence can either be defined
-      explicitly or may depend on the configuration of the
-      resolver.
-
-      Domain-name values use the US-ASCII encoding.  Their canonical
-      format uses lowercase US-ASCII characters.  Internationalized
-      domain names MUST be A-labels as per RFC 5890.";
-      reference
-        "RFC  952: DoD Internet Host Table Specification
-         RFC 1034: Domain Names - Concepts and Facilities
-         RFC 1123: Requirements for Internet Hosts -- Application
-        	  and Support
-         RFC 2782: A DNS RR for specifying the location of services
-        	  (DNS SRV)
-         RFC 5890: Internationalized Domain Names in Applications
-        	  (IDNA): Definitions and Document Framework";
-
-    }
-
-    typedef host {
-      type union {
-        type ip-address;
-        type 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)";
-
-    }
-  }  // module ietf-inet-types
diff --git a/models/openconfig/src/main/yang/comm/ietf-interfaces@2014-05-08.yang b/models/openconfig/src/main/yang/comm/ietf-interfaces@2014-05-08.yang
deleted file mode 100644
index d02aca2..0000000
--- a/models/openconfig/src/main/yang/comm/ietf-interfaces@2014-05-08.yang
+++ /dev/null
@@ -1,703 +0,0 @@
-module ietf-interfaces {
-
-     namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces";
-     prefix if;
-
-     import 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: Thomas Nadeau
-                  <mailto:tnadeau@lucidvision.com>
-
-        WG Chair: Juergen Schoenwaelder
-                  <mailto:j.schoenwaelder@jacobs-university.de>
-
-        Editor:   Martin Bjorklund
-                  <mailto:mbj@tail-f.com>";
-
-     description
-       "This module contains a collection of YANG definitions for
-        managing network interfaces.
-
-        Copyright (c) 2014 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 7223; see
-        the RFC itself for full legal notices.";
-
-     revision 2014-05-08 {
-       description
-         "Initial revision.";
-       reference
-         "RFC 7223: A YANG Data Model for Interface Management";
-     }
-
-     /*
-      * Typedefs
-      */
-
-     typedef interface-ref {
-       type leafref {
-         path "/if:interfaces/if:interface/if:name";
-       }
-       description
-         "This type is used by data models that need to reference
-          configured interfaces.";
-     }
-
-     typedef interface-state-ref {
-       type leafref {
-         path "/if:interfaces-state/if:interface/if:name";
-       }
-       description
-         "This type is used by data models that need to reference
-          the operationally present interfaces.";
-     }
-
-     /*
-      * Identities
-      */
-
-     identity interface-type {
-       description
-         "Base identity from which specific interface types are
-          derived.";
-     }
-
-     /*
-      * Features
-      */
-
-     feature arbitrary-names {
-       description
-         "This feature indicates that the device allows user-controlled
-          interfaces to be named arbitrarily.";
-     }
-
-
-     feature pre-provisioning {
-       description
-         "This feature indicates that the device supports
-          pre-provisioning of interface configuration, i.e., it is
-          possible to configure an interface whose physical interface
-          hardware is not present on the device.";
-     }
-
-     feature if-mib {
-       description
-         "This feature indicates that the device implements
-          the IF-MIB.";
-       reference
-         "RFC 2863: The Interfaces Group MIB";
-     }
-
-     /*
-      * Configuration data nodes
-      */
-
-     container interfaces {
-       description
-         "Interface configuration parameters.";
-
-       list interface {
-         key "name";
-
-         description
-           "The list of configured interfaces on the device.
-
-            The operational state of an interface is available in the
-            /interfaces-state/interface list.  If the configuration of a
-            system-controlled interface cannot be used by the system
-            (e.g., the interface hardware present does not match the
-            interface type), then the configuration is not applied to
-            the system-controlled interface shown in the
-            /interfaces-state/interface list.  If the configuration
-            of a user-controlled interface cannot be used by the system,
-            the configured interface is not instantiated in the
-            /interfaces-state/interface list.";
-
-        leaf name {
-           type string;
-           description
-             "The name of the interface.
-
-              A device MAY restrict the allowed values for this leaf,
-              possibly depending on the type of the interface.
-
-
-              For system-controlled interfaces, this leaf is the
-              device-specific name of the interface.  The 'config false'
-              list /interfaces-state/interface contains the currently
-              existing interfaces on the device.
-
-              If a client tries to create configuration for a
-              system-controlled interface that is not present in the
-              /interfaces-state/interface list, the server MAY reject
-              the request if the implementation does not support
-              pre-provisioning of interfaces or if the name refers to
-              an interface that can never exist in the system.  A
-              NETCONF server MUST reply with an rpc-error with the
-              error-tag 'invalid-value' in this case.
-
-              If the device supports pre-provisioning of interface
-              configuration, the 'pre-provisioning' feature is
-              advertised.
-
-              If the device allows arbitrarily named user-controlled
-              interfaces, the 'arbitrary-names' feature is advertised.
-
-              When a configured user-controlled interface is created by
-              the system, it is instantiated with the same name in the
-              /interface-state/interface list.";
-         }
-
-         leaf description {
-           type string;
-           description
-             "A textual description of the interface.
-
-              A server implementation MAY map this leaf to the ifAlias
-              MIB object.  Such an implementation needs to use some
-              mechanism to handle the differences in size and characters
-              allowed between this leaf and ifAlias.  The definition of
-              such a mechanism is outside the scope of this document.
-
-              Since ifAlias is defined to be stored in non-volatile
-              storage, the MIB implementation MUST map ifAlias to the
-              value of 'description' in the persistently stored
-              datastore.
-
-              Specifically, if the device supports ':startup', when
-              ifAlias is read the device MUST return the value of
-              'description' in the 'startup' datastore, and when it is
-              written, it MUST be written to the 'running' and 'startup'
-              datastores.  Note that it is up to the implementation to
-
-              decide whether to modify this single leaf in 'startup' or
-              perform an implicit copy-config from 'running' to
-              'startup'.
-
-              If the device does not support ':startup', ifAlias MUST
-              be mapped to the 'description' leaf in the 'running'
-              datastore.";
-           reference
-             "RFC 2863: The Interfaces Group MIB - ifAlias";
-         }
-
-         leaf type {
-           type identityref {
-             base interface-type;
-           }
-           mandatory true;
-           description
-             "The type of the interface.
-
-              When an interface entry is created, a server MAY
-              initialize the type leaf with a valid value, e.g., if it
-              is possible to derive the type from the name of the
-              interface.
-
-              If a client tries to set the type of an interface to a
-              value that can never be used by the system, e.g., if the
-              type is not supported or if the type does not match the
-              name of the interface, the server MUST reject the request.
-              A NETCONF server MUST reply with an rpc-error with the
-              error-tag 'invalid-value' in this case.";
-           reference
-             "RFC 2863: The Interfaces Group MIB - ifType";
-         }
-
-         leaf enabled {
-           type boolean;
-           default "true";
-           description
-             "This leaf contains the configured, desired state of the
-              interface.
-
-              Systems that implement the IF-MIB use the value of this
-              leaf in the 'running' datastore to set
-              IF-MIB.ifAdminStatus to 'up' or 'down' after an ifEntry
-              has been initialized, as described in RFC 2863.
-
-              Changes in this leaf in the 'running' datastore are
-              reflected in ifAdminStatus, but if ifAdminStatus is
-              changed over SNMP, this leaf is not affected.";
-           reference
-             "RFC 2863: The Interfaces Group MIB - ifAdminStatus";
-         }
-
-         leaf link-up-down-trap-enable {
-           if-feature if-mib;
-           type enumeration {
-             enum enabled {
-               value 1;
-             }
-             enum disabled {
-               value 2;
-             }
-           }
-           description
-             "Controls whether linkUp/linkDown SNMP notifications
-              should be generated for this interface.
-
-              If this node is not configured, the value 'enabled' is
-              operationally used by the server for interfaces that do
-              not operate on top of any other interface (i.e., there are
-              no 'lower-layer-if' entries), and 'disabled' otherwise.";
-           reference
-             "RFC 2863: The Interfaces Group MIB -
-                        ifLinkUpDownTrapEnable";
-         }
-       }
-     }
-
-     /*
-      * Operational state data nodes
-      */
-
-     container interfaces-state {
-       config false;
-       description
-         "Data nodes for the operational state of interfaces.";
-
-       list interface {
-         key "name";
-
-         description
-           "The list of interfaces on the device.
-
-            System-controlled interfaces created by the system are
-            always present in this list, whether they are configured or
-            not.";
-
-         leaf name {
-           type string;
-           description
-             "The name of the interface.
-
-              A server implementation MAY map this leaf to the ifName
-              MIB object.  Such an implementation needs to use some
-              mechanism to handle the differences in size and characters
-              allowed between this leaf and ifName.  The definition of
-              such a mechanism is outside the scope of this document.";
-           reference
-             "RFC 2863: The Interfaces Group MIB - ifName";
-         }
-
-         leaf type {
-           type identityref {
-             base interface-type;
-           }
-           mandatory true;
-           description
-             "The type of the interface.";
-           reference
-             "RFC 2863: The Interfaces Group MIB - ifType";
-         }
-
-         leaf admin-status {
-           if-feature if-mib;
-           type enumeration {
-             enum up {
-               value 1;
-               description
-                 "Ready to pass packets.";
-             }
-             enum down {
-               value 2;
-               description
-                 "Not ready to pass packets and not in some test mode.";
-             }
-
-             enum testing {
-               value 3;
-               description
-                 "In some test mode.";
-             }
-           }
-           mandatory true;
-           description
-             "The desired state of the interface.
-
-              This leaf has the same read semantics as ifAdminStatus.";
-           reference
-             "RFC 2863: The Interfaces Group MIB - ifAdminStatus";
-         }
-
-         leaf oper-status {
-           type enumeration {
-             enum up {
-               value 1;
-               description
-                 "Ready to pass packets.";
-             }
-             enum down {
-               value 2;
-               description
-                 "The interface does not pass any packets.";
-             }
-             enum testing {
-               value 3;
-               description
-                 "In some test mode.  No operational packets can
-                  be passed.";
-             }
-             enum unknown {
-               value 4;
-               description
-                 "Status cannot be determined for some reason.";
-             }
-             enum dormant {
-               value 5;
-               description
-                 "Waiting for some external event.";
-             }
-             enum not-present {
-               value 6;
-               description
-                 "Some component (typically hardware) is missing.";
-             }
-
-             enum lower-layer-down {
-               value 7;
-               description
-                 "Down due to state of lower-layer interface(s).";
-             }
-           }
-           mandatory true;
-           description
-             "The current operational state of the interface.
-
-              This leaf has the same semantics as ifOperStatus.";
-           reference
-             "RFC 2863: The Interfaces Group MIB - ifOperStatus";
-         }
-
-         leaf last-change {
-           type yang:date-and-time;
-           description
-             "The time the interface entered its current operational
-              state.  If the current state was entered prior to the
-              last re-initialization of the local network management
-              subsystem, then this node is not present.";
-           reference
-             "RFC 2863: The Interfaces Group MIB - ifLastChange";
-         }
-
-         leaf if-index {
-           if-feature if-mib;
-           type int32 {
-             range "1..2147483647";
-           }
-           mandatory true;
-           description
-             "The ifIndex value for the ifEntry represented by this
-              interface.";
-           reference
-             "RFC 2863: The Interfaces Group MIB - ifIndex";
-         }
-
-         leaf phys-address {
-           type yang:phys-address;
-           description
-             "The interface's address at its protocol sub-layer.  For
-              example, for an 802.x interface, this object normally
-              contains a Media Access Control (MAC) address.  The
-              interface's media-specific modules must define the bit
-
-
-              and byte ordering and the format of the value of this
-              object.  For interfaces that do not have such an address
-              (e.g., a serial line), this node is not present.";
-           reference
-             "RFC 2863: The Interfaces Group MIB - ifPhysAddress";
-         }
-
-         leaf-list higher-layer-if {
-           type interface-state-ref;
-           description
-             "A list of references to interfaces layered on top of this
-              interface.";
-           reference
-             "RFC 2863: The Interfaces Group MIB - ifStackTable";
-         }
-
-         leaf-list lower-layer-if {
-           type interface-state-ref;
-           description
-             "A list of references to interfaces layered underneath this
-              interface.";
-           reference
-             "RFC 2863: The Interfaces Group MIB - ifStackTable";
-         }
-
-         leaf speed {
-           type yang:gauge64;
-           units "bits/second";
-           description
-               "An estimate of the interface's current bandwidth in bits
-                per second.  For interfaces that do not vary in
-                bandwidth or for those where no accurate estimation can
-                be made, this node should contain the nominal bandwidth.
-                For interfaces that have no concept of bandwidth, this
-                node is not present.";
-           reference
-             "RFC 2863: The Interfaces Group MIB -
-                        ifSpeed, ifHighSpeed";
-         }
-
-
-         container statistics {
-           description
-             "A collection of interface-related statistics objects.";
-
-           leaf discontinuity-time {
-             type yang:date-and-time;
-             mandatory true;
-             description
-               "The time on the most recent occasion at which any one or
-                more of this interface's counters suffered a
-                discontinuity.  If no such discontinuities have occurred
-                since the last re-initialization of the local management
-                subsystem, then this node contains the time the local
-                management subsystem re-initialized itself.";
-           }
-
-           leaf in-octets {
-             type yang:counter64;
-             description
-               "The total number of octets received on the interface,
-                including framing characters.
-
-                Discontinuities in the value of this counter can occur
-                at re-initialization of the management system, and at
-                other times as indicated by the value of
-                'discontinuity-time'.";
-             reference
-               "RFC 2863: The Interfaces Group MIB - ifHCInOctets";
-           }
-
-           leaf in-unicast-pkts {
-             type yang:counter64;
-             description
-               "The number of packets, delivered by this sub-layer to a
-                higher (sub-)layer, that were not addressed to a
-                multicast or broadcast address at this sub-layer.
-
-                Discontinuities in the value of this counter can occur
-                at re-initialization of the management system, and at
-                other times as indicated by the value of
-                'discontinuity-time'.";
-             reference
-               "RFC 2863: The Interfaces Group MIB - ifHCInUcastPkts";
-           }
-
-           leaf in-broadcast-pkts {
-             type yang:counter64;
-             description
-               "The number of packets, delivered by this sub-layer to a
-                higher (sub-)layer, that were addressed to a broadcast
-                address at this sub-layer.
-
-                Discontinuities in the value of this counter can occur
-                at re-initialization of the management system, and at
-                other times as indicated by the value of
-                'discontinuity-time'.";
-             reference
-               "RFC 2863: The Interfaces Group MIB -
-                          ifHCInBroadcastPkts";
-           }
-
-           leaf in-multicast-pkts {
-             type yang:counter64;
-             description
-               "The number of packets, delivered by this sub-layer to a
-                higher (sub-)layer, that were addressed to a multicast
-                address at this sub-layer.  For a MAC-layer protocol,
-                this includes both Group and Functional addresses.
-
-                Discontinuities in the value of this counter can occur
-                at re-initialization of the management system, and at
-                other times as indicated by the value of
-                'discontinuity-time'.";
-             reference
-               "RFC 2863: The Interfaces Group MIB -
-                          ifHCInMulticastPkts";
-           }
-
-           leaf in-discards {
-             type yang:counter32;
-             description
-               "The number of inbound packets that were chosen to be
-                discarded even though no errors had been detected to
-                prevent their being deliverable to a higher-layer
-                protocol.  One possible reason for discarding such a
-                packet could be to free up buffer space.
-
-                Discontinuities in the value of this counter can occur
-                at re-initialization of the management system, and at
-                other times as indicated by the value of
-                'discontinuity-time'.";
-
-             reference
-               "RFC 2863: The Interfaces Group MIB - ifInDiscards";
-           }
-
-           leaf in-errors {
-             type yang:counter32;
-             description
-               "For packet-oriented interfaces, the number of inbound
-                packets that contained errors preventing them from being
-                deliverable to a higher-layer protocol.  For character-
-                oriented or fixed-length interfaces, the number of
-                inbound transmission units that contained errors
-                preventing them from being deliverable to a higher-layer
-                protocol.
-
-                Discontinuities in the value of this counter can occur
-                at re-initialization of the management system, and at
-                other times as indicated by the value of
-                'discontinuity-time'.";
-             reference
-               "RFC 2863: The Interfaces Group MIB - ifInErrors";
-           }
-
-           leaf in-unknown-protos {
-             type yang:counter32;
-             description
-               "For packet-oriented interfaces, the number of packets
-                received via the interface that were discarded because
-                of an unknown or unsupported protocol.  For
-                character-oriented or fixed-length interfaces that
-                support protocol multiplexing, the number of
-                transmission units received via the interface that were
-                discarded because of an unknown or unsupported protocol.
-                For any interface that does not support protocol
-                multiplexing, this counter is not present.
-
-                Discontinuities in the value of this counter can occur
-                at re-initialization of the management system, and at
-                other times as indicated by the value of
-                'discontinuity-time'.";
-             reference
-               "RFC 2863: The Interfaces Group MIB - ifInUnknownProtos";
-           }
-
-           leaf out-octets {
-             type yang:counter64;
-             description
-               "The total number of octets transmitted out of the
-                interface, including framing characters.
-
-                Discontinuities in the value of this counter can occur
-                at re-initialization of the management system, and at
-                other times as indicated by the value of
-                'discontinuity-time'.";
-             reference
-               "RFC 2863: The Interfaces Group MIB - ifHCOutOctets";
-           }
-
-           leaf out-unicast-pkts {
-             type yang:counter64;
-             description
-               "The total number of packets that higher-level protocols
-                requested be transmitted, and that were not addressed
-                to a multicast or broadcast address at this sub-layer,
-                including those that were discarded or not sent.
-
-                Discontinuities in the value of this counter can occur
-                at re-initialization of the management system, and at
-                other times as indicated by the value of
-                'discontinuity-time'.";
-             reference
-               "RFC 2863: The Interfaces Group MIB - ifHCOutUcastPkts";
-           }
-
-           leaf out-broadcast-pkts {
-             type yang:counter64;
-             description
-               "The total number of packets that higher-level protocols
-                requested be transmitted, and that were addressed to a
-                broadcast address at this sub-layer, including those
-                that were discarded or not sent.
-
-                Discontinuities in the value of this counter can occur
-                at re-initialization of the management system, and at
-                other times as indicated by the value of
-                'discontinuity-time'.";
-             reference
-               "RFC 2863: The Interfaces Group MIB -
-                          ifHCOutBroadcastPkts";
-           }
-
-           leaf out-multicast-pkts {
-             type yang:counter64;
-             description
-               "The total number of packets that higher-level protocols
-                requested be transmitted, and that were addressed to a
-                multicast address at this sub-layer, including those
-                that were discarded or not sent.  For a MAC-layer
-                protocol, this includes both Group and Functional
-                addresses.
-
-                Discontinuities in the value of this counter can occur
-                at re-initialization of the management system, and at
-                other times as indicated by the value of
-                'discontinuity-time'.";
-             reference
-               "RFC 2863: The Interfaces Group MIB -
-                          ifHCOutMulticastPkts";
-           }
-
-           leaf out-discards {
-             type yang:counter32;
-             description
-               "The number of outbound packets that were chosen to be
-                discarded even though no errors had been detected to
-                prevent their being transmitted.  One possible reason
-                for discarding such a packet could be to free up buffer
-                space.
-
-                Discontinuities in the value of this counter can occur
-                at re-initialization of the management system, and at
-                other times as indicated by the value of
-                'discontinuity-time'.";
-             reference
-               "RFC 2863: The Interfaces Group MIB - ifOutDiscards";
-           }
-
-           leaf out-errors {
-             type yang:counter32;
-             description
-               "For packet-oriented interfaces, the number of outbound
-                packets that could not be transmitted because of errors.
-                For character-oriented or fixed-length interfaces, the
-                number of outbound transmission units that could not be
-                transmitted because of errors.
-
-                Discontinuities in the value of this counter can occur
-                at re-initialization of the management system, and at
-                other times as indicated by the value of
-                'discontinuity-time'.";
-             reference
-               "RFC 2863: The Interfaces Group MIB - ifOutErrors";
-           }
-         }
-       }
-     }
-   }
diff --git a/models/openconfig/src/main/yang/comm/ietf-yang-types@2013-07-15.yang b/models/openconfig/src/main/yang/comm/ietf-yang-types@2013-07-15.yang
deleted file mode 100644
index 9a543fa..0000000
--- a/models/openconfig/src/main/yang/comm/ietf-yang-types@2013-07-15.yang
+++ /dev/null
@@ -1,490 +0,0 @@
-  module ietf-yang-types {
-
-    yang-version 1;
-
-    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";
-
-    }
-
-
-    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 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 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";
-
-    }
-
-    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)";
-
-    }
-
-    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 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";
-
-    }
-
-    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";
-
-    }
-
-    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";
-
-    }
-
-    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.";
-    }
-  }  // module ietf-yang-types
-