<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.19 (Ruby 3.3.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-zheng-ccamp-client-tunnel-yang-15" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.23.2 -->
  <front>
    <title abbrev="Client Tunnel YANG Model">A YANG Data Model for Client-layer Tunnel</title>
    <seriesInfo name="Internet-Draft" value="draft-zheng-ccamp-client-tunnel-yang-15"/>
    <author initials="C." surname="Yu" fullname="Chaode Yu">
      <organization>Huawei Technologies</organization>
      <address>
        <email>yuchaode@huawei.com</email>
      </address>
    </author>
    <author initials="H." surname="Zheng" fullname="Haomian Zheng">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>H1, Huawei Xiliu Beipo Village, Songshan Lake</street>
          <city>Dongguan</city>
          <region>Guangdong</region>
          <code>523808</code>
          <country>China</country>
        </postal>
        <email>zhenghaomian@huawei.com</email>
      </address>
    </author>
    <author initials="A." surname="Guo" fullname="Aihua Guo">
      <organization>Futurewei</organization>
      <address>
        <email>aihuaguo@futurewei.com</email>
      </address>
    </author>
    <author initials="I." surname="Busi" fullname="Italo Busi">
      <organization>Huawei Technologies</organization>
      <address>
        <email>italo.busi@huawei.com</email>
      </address>
    </author>
    <author initials="Y." surname="Xu" fullname="Yunbin Xu">
      <organization>CAICT</organization>
      <address>
        <email>xuyunbin@caict.ac.cn</email>
      </address>
    </author>
    <author initials="Y." surname="Zhao" fullname="Yang Zhao">
      <organization>China Mobile</organization>
      <address>
        <email>zhaoyangyjy@chinamobile.com</email>
      </address>
    </author>
    <author initials="X." surname="Liu" fullname="Xufeng Liu">
      <organization>Alef Edge</organization>
      <address>
        <email>xufeng.liu.ietf@gmail.com</email>
      </address>
    </author>
    <date year="2024" month="October" day="14"/>
    <area>Routing</area>
    <workgroup>Common Control and Measurement Plane</workgroup>
    <keyword>next generation</keyword>
    <keyword>unicorn</keyword>
    <keyword>sparkling distributed ledger</keyword>
    <abstract>
      <?line 88?>

<t>A transport network is a server-layer network to provide connectivity
services to its client.  In this draft the tunnel of client is
described, with the definition of client tunnel YANG model.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://italobusi.github.io/eth-te-tunnel/draft-zheng-ccamp-client-tunnel-yang.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-zheng-ccamp-client-tunnel-yang/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Common Control and Measurement Plane Working Group mailing list (<eref target="mailto:ccamp@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/ccamp/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/ccamp/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/italobusi/eth-te-tunnel"/>.</t>
    </note>
  </front>
  <middle>
    <?line 94?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>A transport network is a server-layer network designed to provide
   connectivity services for a client-layer network to carry the client
   traffic transparently across the server-layer network resources.  The
   tunnel model in Traffic-Engineered network has been defined in both
   generic way and technology-specific way.  The generic model, which is
   the base TE tunnel YANG model, can be found at
   <xref target="I-D.ietf-teas-yang-te"/>.  Technology-specific models, such as OTN/
   WSON tunnel model, have also been defined in
   <xref target="I-D.ietf-ccamp-otn-tunnel-model"/> and
   <xref target="I-D.ietf-ccamp-wson-tunnel-model"/> respectively.  Corresponding
   tunnel on client-layer is also required, to have a complete topology
   view from the perspective of network controllers.</t>
      <t>This document defines a data model of all client-layer tunnel, using
   YANG language defined in <xref target="RFC7950"/>.  The model is augmenting the
   generic TE tunnel model, and can be used by applications exposing to
   a network controller via a REST interface.  Furthermore, it can be
   used by an application to describe the client tunnel that constructed
   above the server-layer network.  It is also worth noting that the
   client layer network will only need the tunnel model when there is a
   demand for switching techniques, such as Carrier Ethernet and MPLS-
   TP.  The transparent signals do not need this model.</t>
    </section>
    <section anchor="terminology-and-notations">
      <name>Terminology and Notations</name>
      <t>A simplified graphical representation of the data model is used in
   this document.  The meaning of the symbols in the YANG data tree
   presented later in this document is defined in <xref target="RFC8340"/>.  They are
   provided below for reference.</t>
      <ul spacing="normal">
        <li>
          <t>Brackets "[" and "]" enclose list keys.</t>
        </li>
        <li>
          <t>Abbreviations before data node names: "rw" means configuration
(read-write) and "ro" state data (read-only).</t>
        </li>
        <li>
          <t>Symbols after data node names: "?" means an optional node, "!"
means a presence container, and "*" denotes a list and leaf-list.</t>
        </li>
        <li>
          <t>Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":").</t>
        </li>
        <li>
          <t>Ellipsis ("...") stands for contents of subtrees that are not
shown.</t>
        </li>
      </ul>
    </section>
    <section anchor="yang-model-for-client-layer-tunnel">
      <name>YANG Model for Client-layer Tunnel</name>
      <section anchor="yang-tree-for-ethernet-tunnel">
        <name>YANG Tree for Ethernet Tunnel</name>
        <figure anchor="fig-eth-topology-tree">
          <name>Ethernet TE Tunnel YANG tree</name>
          <artwork type="ascii-art" name="ietf-eth-te-tunnel.tree"><![CDATA[
module: ietf-eth-te-tunnel

  augment /te:te/te:tunnels/te:tunnel:
    +--rw src-eth-tunnel-endpoint
    |  +--rw vlanid?     etht-types:vlanid
    |  +--rw tag-type?   etht-types:eth-tag-type
    +--rw dst-eth-tunnel-endpoint
    |  +--rw vlanid?     etht-types:vlanid
    |  +--rw tag-type?   etht-types:eth-tag-type
    +--rw bandwidth-profile
       +--rw bandwidth-profile-type?
       |       etht-types:bandwidth-profile-type
       +--rw CIR?                      uint64
       +--rw CBS?                      uint64
       +--rw EIR?                      uint64
       +--rw EBS?                      uint64
       +--rw color-aware?              boolean
       +--rw coupling-flag?            boolean
]]></artwork>
        </figure>
      </section>
      <section anchor="yang-tree-for-tunnel-of-other-client-signal-model">
        <name>YANG Tree for Tunnel of other Client Signal Model</name>
        <t>This section will be completed later.</t>
      </section>
    </section>
    <section anchor="yang-code-for-client-layer-tunnel">
      <name>YANG Code for Client-layer Tunnel</name>
      <section anchor="the-eth-tunnel-yang-code">
        <name>The ETH Tunnel YANG Code</name>
        <figure anchor="fig-te-yang">
          <name>Ethernet TE Tunnel YANG module</name>
          <sourcecode type="yang" markers="true" name="ietf-eth-te-tunnel@2018-03-01.yang"><![CDATA[
module ietf-eth-te-tunnel {

    namespace "urn:ietf:params:xml:ns:yang:ietf-eth-te-tunnel";

    prefix "eth-tunnel";

    import ietf-te {
        prefix "te";
    }

    import ietf-eth-tran-types {
        prefix "etht-types";
    }

    organization
        "Internet Engineering Task Force (IETF) CCAMP WG";
  contact
    "
      WG List: <mailto:ccamp@ietf.org>

      ID-draft editor:
        Haomian Zheng (zhenghaomian@huawei.com);
        Italo Busi (italo.busi@huawei.com);
        Aihua Guo (aihuaguo.ietf@gmail.com);
        Yunbin Xu (xuyunbin@caict.ac.cn);
        Yang Zhao (zhaoyangyjy@chinamobile.com);
        Xufeng Liu (xufeng.liu.ietf@gmail.com);
    ";

    description
        "This module defines a model for ETH transport tunnel";

    revision 2018-03-01 {
        description
            "Initial revision";
        reference
            "draft-zheng-ccamp-client-tunnel-yang";
    }

    grouping eth-tunnel-endpoint {
        description "Parameters for ETH tunnel.";

        leaf vlanid {
            type etht-types:vlanid;
            description
                "VLAN tag id.";
        }

        leaf tag-type {
            type etht-types:eth-tag-type;
            description "VLAN tag type.";
        }
    }

    augment "/te:te/te:tunnels/te:tunnel" {
        description
            "Augment with additional parameters required for ETH
            service.";

        container src-eth-tunnel-endpoint {
            description
                "Source ETH tunnel endpoint.";

            uses eth-tunnel-endpoint;
        }
        container dst-eth-tunnel-endpoint {
            description
                "Destination ETH tunnel endpoint.";

            uses eth-tunnel-endpoint;
        }

        container bandwidth-profile {
            description
                "ETH tunnel bandwidth profile specification.";

            uses etht-types:etht-bandwidth-profiles;
        }
    }
}
]]></sourcecode>
        </figure>
      </section>
      <section anchor="other-client-layer-tunnel-yang-code">
        <name>Other Client-layer Tunnel YANG Code</name>
        <t>TBD.</t>
      </section>
    </section>
    <section anchor="considerations-and-open-issue">
      <name>Considerations and Open Issue</name>
      <t>Editor Notes: This section is used to note temporary discussion/
conclusion that to be fixed in the future version, and will be
removed before publication.  This is a part of L2 work, need to
discuss how to go with other L2 network models.  The expectation is
to include all potential L2 TE part in this work.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>TBD.</t>
    </section>
    <section anchor="manageability-considerations">
      <name>Manageability Considerations</name>
      <t>TBD.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The data following the model defined in this document is exchanged
via, for example, the interface between an orchestrator and a
transport network controller.  The security concerns mentioned in
<xref target="I-D.ietf-teas-yang-te"/> also applies to this document.</t>
      <t>The YANG module defined in this document can be accessed via the
RESTCONF protocol defined in <xref target="RFC8040"/>, or maybe via the NETCONF
protocol <xref target="RFC6241"/>.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="I-D.ietf-teas-yang-te">
          <front>
            <title>A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths and Interfaces</title>
            <author fullname="Tarek Saad" initials="T." surname="Saad">
              <organization>Cisco Systems Inc</organization>
            </author>
            <author fullname="Rakesh Gandhi" initials="R." surname="Gandhi">
              <organization>Cisco Systems Inc</organization>
            </author>
            <author fullname="Xufeng Liu" initials="X." surname="Liu">
              <organization>Alef Edge</organization>
            </author>
            <author fullname="Vishnu Pavan Beeram" initials="V. P." surname="Beeram">
              <organization>Juniper Networks</organization>
            </author>
            <author fullname="Igor Bryskin" initials="I." surname="Bryskin">
              <organization>Individual</organization>
            </author>
            <date day="9" month="October" year="2024"/>
            <abstract>
              <t>   This document defines a YANG data model for the provisioning and
   management of Traffic Engineering (TE) tunnels, Label Switched Paths
   (LSPs), and interfaces.  The model covers data that is independent of
   any technology or dataplane encapsulation and is divided into two
   YANG modules that cover device-specific, and device independent data.

   This model covers data for configuration, operational state, remote
   procedural calls, and event notifications.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-teas-yang-te-37"/>
        </reference>
        <reference anchor="RFC7950">
          <front>
            <title>The YANG 1.1 Data Modeling Language</title>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <date month="August" year="2016"/>
            <abstract>
              <t>YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7950"/>
          <seriesInfo name="DOI" value="10.17487/RFC7950"/>
        </reference>
        <reference anchor="RFC8040">
          <front>
            <title>RESTCONF Protocol</title>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <date month="January" year="2017"/>
            <abstract>
              <t>This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8040"/>
          <seriesInfo name="DOI" value="10.17487/RFC8040"/>
        </reference>
        <reference anchor="RFC6241">
          <front>
            <title>Network Configuration Protocol (NETCONF)</title>
            <author fullname="R. Enns" initials="R." role="editor" surname="Enns"/>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/>
            <author fullname="A. Bierman" initials="A." role="editor" surname="Bierman"/>
            <date month="June" year="2011"/>
            <abstract>
              <t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6241"/>
          <seriesInfo name="DOI" value="10.17487/RFC6241"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="I-D.ietf-ccamp-otn-tunnel-model">
          <front>
            <title>OTN Tunnel YANG Model</title>
            <author fullname="Haomian Zheng" initials="H." surname="Zheng">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Italo Busi" initials="I." surname="Busi">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Sergio Belotti" initials="S." surname="Belotti">
              <organization>Nokia</organization>
            </author>
            <author fullname="Victor Lopez" initials="V." surname="Lopez">
              <organization>Nokia</organization>
            </author>
            <author fullname="Yunbin Xu" initials="Y." surname="Xu">
              <organization>CAICT</organization>
            </author>
            <date day="6" month="June" year="2024"/>
            <abstract>
              <t>   This document describes the YANG data model for tunnels in OTN TE
   networks.  The model can be used to do the configuration in order to
   establish the tunnel in OTN network.  This work is independent with
   the control plane protocols.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-ccamp-otn-tunnel-model-21"/>
        </reference>
        <reference anchor="I-D.ietf-ccamp-wson-tunnel-model">
          <front>
            <title>A Yang Data Model for WSON Tunnel</title>
            <author fullname="Young Lee" initials="Y." surname="Lee">
              <organization>Samsung</organization>
            </author>
            <author fullname="Haomian Zheng" initials="H." surname="Zheng">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Aihua Guo" initials="A." surname="Guo">
              <organization>Futurewei</organization>
            </author>
            <author fullname="Victor Lopez" initials="V." surname="Lopez">
              <organization>Nokia</organization>
            </author>
            <author fullname="Daniel King" initials="D." surname="King">
              <organization>Lancaster University</organization>
            </author>
            <author fullname="Bin Yeong Yoon" initials="B. Y." surname="Yoon">
              <organization>ETRI</organization>
            </author>
            <author fullname="Ricard Vilalta" initials="R." surname="Vilalta">
              <organization>CTTC</organization>
            </author>
            <date day="9" month="July" year="2023"/>
            <abstract>
              <t>   This document provides a YANG data model for WSON TE tunnel.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-ccamp-wson-tunnel-model-09"/>
        </reference>
        <reference anchor="RFC8340">
          <front>
            <title>YANG Tree Diagrams</title>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="L. Berger" initials="L." role="editor" surname="Berger"/>
            <date month="March" year="2018"/>
            <abstract>
              <t>This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="215"/>
          <seriesInfo name="RFC" value="8340"/>
          <seriesInfo name="DOI" value="10.17487/RFC8340"/>
        </reference>
      </references>
    </references>
    <?line 292?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>We would like to thank Igor Bryskin and Daniel King for their
comments and discussions.</t>
    </section>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false">
      <name>Contributors</name>
      <contact initials="Z." surname="Liu" fullname="Zhe Liu">
        <organization>Huawei Technologies</organization>
        <address>
          <email>liuzhe123@huawei.com</email>
        </address>
      </contact>
      <contact initials="S." surname="Belotti" fullname="Sergio Belotti">
        <organization>Nokia</organization>
        <address>
          <email>sergio.belotti@nokia.com</email>
        </address>
      </contact>
      <contact initials="Y." surname="Yao" fullname="Yingxi Yao">
        <organization>Shanghai Bell</organization>
        <address>
          <email>yingxi.yao@nokia-sbell.com</email>
        </address>
      </contact>
      <contact initials="G." surname="Fioccola" fullname="Giuseppe Fioccola">
        <organization>Huawei Technologies</organization>
        <address>
          <email>giuseppe.fioccola@huawei.com</email>
        </address>
      </contact>
      <contact initials="Y." surname="Zheng" fullname="Yanlei Zheng">
        <organization>China Unicom</organization>
        <address>
          <email>zhengyanlei@chinaunicom.cn</email>
        </address>
      </contact>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA8VZW3PbxhV+x6/YwC9yK1C+JKnL1JVkWbI1tWWPxcZJLw9L
YEluBGKR3YUoxlF/e79zdkECImlbM50pZ2yR2LPnfkeWZYnXvlRDkR6Ln48v
XomX0kvx1hSqFBNjxUmpVeWzUi6VFaOmqlSZJnI8tuoad8JpfB7u89U0yaVX
U2OXQ+F8kSSFySs5B5nCyonPfpupaprluZzXWR4oeMaRLSUOHn+XuGY8185p
U/lljXvnp6MzIR4IWToDwroqVK3wX+XTfZGqQntjtSzpx/nxC/wB7+n5h9FZ
mlTNfKzsMCnA0jDJTeVU5Ro3FN42KoEYTxNplQTWD6bxupqmycLYq6k1TU0y
mvncVOIEnFhTClkV4q2SrrFqTrK/L2Wl0uRKLXGpGCYiE5W68WKqKmWlhwD0
qKl0bix/dbW0VyXIiEI7b/W48aoQpSqmyibXqmrApBD3oy5E0FL6EYwT6ld0
nZ7PpS7xnFV9pJWfDIyd0oG0+QwHM+9rNzw4IDh6pK/VoAU7oAcHY2sWTh0w
hgO6OdV+1ozJCF6WZtw4faD8LPMq2pBgSuja+Q7+FewgXB9o07918DWeMZj5
OfAnsvEzY0lPGf4JEXzrZCbhfOLnhp9BgKF43ciF0mKk8lllSjPVyvGhCnpZ
NjnfOZox3CA38zs4X0sz17IS/yC+vowXBlUKcr9+vN/C/KRL3YgXStdG/KjL
Uk7Vvrg01dTNgPeNvFJ8M9cewfISz6eNrPiRVVO4z1C8woNpYSL9HPwOxXdP
nj579Cw+aOAcS5JfV7IrHitzFiTYLeKxxhGImLV4Z42HhwG8i00S3LQxR5P2
dAuyc7KzeAFDf7UR2DUG5Bu7efy5qca6Ej91THtyfH4y6uK5aZYMdZRLnfuB
zAd5dRcNFAlTyo6orDRkrbEuVV930pDLLX9ZHuUEM2eQLbz91EygZvFGd5g7
LtVEnCKk+wwS4ADuwCF2NKXHjJCyUkgFm14Nz+vj/oI6gR52f/zk6W5tXioL
z4JPlsb7jqEuzJXuOZBjwME4AB5VdL7NOkg5Nxra7ej1Et4N39NEpezFHAMP
ltIEfJkD+nIL1le6caqulTjTJs9NKb9aBdN4czCJNz/jWLIqgelOeAen+Dsl
7flGQC35SnAKzutzcrSkMnaOfH+N9J3oatL5lWRZJuQYuUHmPkmOUXhk5Wpj
PUqFp1ojtBOStH2tbKy17Yk3orbmWiOxwUkqlQMpUkVCwDpXjgC0dyIky4EQ
55XwM+DjfIqvSoQEKswkAoFaUiiXw+FUsS8WSMgMV6iJrjSVrA6s79T2OdX2
QZBnrosCEZM8AEGUpqLJudaRtu4nIDjR0wolcC1pwlltLaxYCUstiYysbSoq
l9YuWZQAQXjAymSi88gSCn3ly6WQuTXOMehWpqxyprGgCIWOZsxQVATrQCAX
jQLi7LSa6kopCwna2zPpxFipKmgUBwAfGz8jNNwXgJ+FXHI1960PLzNXq1xP
wlmgu4JmqjDVTOczMh/xg+OxdEqMTjeNtA9dgKaCwhoQkayKT5++Oc9ecu5B
3ZUuNFte3d4StS18MCq3LxzKpIBM70YXB4To4+W7i54+9iHyteLm7K7ggfDh
inAo7cZXbV1nBLe3pIztsAtnNoBhn5q9Q5WkqhNj6YmpCh3CuHX5qu8r5IXE
o1W/NtqS88NrAutwuHldKo9wMTXrgfBca7UQE2vmrO5a2ZYsRUhr7jw0ZyVO
BxwAI44/kzfcowVdkP8X1FsHB8J1WZZ97gLT+wKVMEjB9kSHh45gqrrOBEt+
ODv505+/exRsB96iX4JMMyWy1AX64LmtE60dJRqN/C/6CRJmIcZwyboudc59
qxPqpjaOEXFil1skhoYkDj6cXo7AmFd2InMFls4aC+p2biy6He0jGcKyolR1
iZEh2pzUieCWYT+TnqgihyLRKPYUOTbXamcIUyb0K4PjCZJcZaJapG91E8n0
o3+BNg2+gzyBwC66OTRoeYEyQE+tYgKEp0CFgDYpPzkkVCoO0xDb+tdGdWLo
BDlKg9Yp3QfB0NK/f3PJVWn0Ppqzk64E5UdIAY8iCVqeQLnNxw8QvXauQ/gy
wgvjgw1jQnYazo2Yxs2plTXSiCwRBTWiBhRkm/O5CqydFCTYWiGKfderW69T
siJJ4123nI8NONWsnuC/jI/aYsIRCdLAgwnBBsBusND3rp8fws+fPf125ecQ
z0ZMXCrgSmhOFqx4qyYwSQX/Q4kSL1BtrxQqY/qvf6aslPTfqcBxaZA0S8xe
AkObY9hjHmh1dPuxAraoiIomCmoVMC+mdpGyxI5ccaKnTRzw9jA+FtnCaq8e
BkrWpJgFIGLAEgDIox4yvcuoJ1RoKGGT0GFLB0FiaqIBcxEExttv0iSeRW3m
3Bl4CaXZENPpH1JoEb7CWYdFpcelkpOMfjEP79m5ZsDgVlrJZwZlNuYF/CaS
bv/Ob7IAR1UyxyQLC3ADQQm0hBftpcM0CHlalrp2MOheOhgM0oekkKoINZwY
BnVHjoNRn9zDhbgk5OA8cTOzqNi312uFXRsJQEWwERAx1Cq8Woj/4IP4y7XO
pPUJHLyhtQfXmd4gShETc6g48GroFf/PZ279dch94R+zzC6Es3nAEYqUqora
6NB+iN9boGskcl0cCm4n/QxzLUZ2NwyP+6BeTvn0sA/KJOJRh3rh/P+R+hg2
XegCh4jISTtE7T4OqFug3+PfDp3tN/pYT84/HIqtnwaSf//tHegXl/eAPr0X
7tN74aYQsZlcwMnv3Bobg/Cs7oI3NW2Kskkpp4fbwMmrk09D8QDZKDhBbF4y
CinBu73n6ToYTnu7OoJBarRc9TJKPs/TzYAYMNjtliAbrQYLQxRiaIpLrlch
ZJOEmyGneDwIlXWsVs1WrAPrOD+hNPi5MKeqczp63ZODLsUIp5Y2BveW2Baf
ktXsh+qKVJc2thoS4BDFVs7d8GZeDis3JDzDTQTpDwEBMu9E34h0HXftCQot
zT2xyQbB1mTtFa8ASg9uNy8wOlT+EApbLq/jpI8EUysC+be4b4yf9JwaMrJ7
O6NQqR5JdyXODIYbsUdb1Yfi5OT47Xvx8RWj5FKSh+yRRlQfX4k3mtZ5f6Ex
2Jthf5341yTCnb/MwtQZ9rHDFSe9LZrY27GXevjD6sJ6jST2tu6HOrCr/ZXY
a1dUd/YrHeDVIknsbdsXdSHbXRHxu3MX1Lmw3gMR7h2rngjfektoeeu+2Uax
tyMfXg8P81UFJPdfT9h996M2hrbm4smjx8+yR0+zR487brSNXPQUzP3cEobr
6VqsVVfVv/E169q+j/JKmzxwS7HazqNI31NQIk9Yt5Y8JKVWYPpQYxMrXAcR
fShUNuvdDz2YXUphMX98c3xBFVHoYtBRyu0d4m1h/AL5bg3dyUSHKMH1yXaI
t01K+pkuJf0a4x9HRKGPKwodG856rfx2YG6t0EMQtzM9k6w60l3N0R1NfdYI
l7yL6VhftFh6NOnTcDu7Se6uDvs87mih7sPjS+UwXIZJ6n/F6BZON7qj+/DY
4WuFR7R42q0Pi7CT3Y4n+2yDGbfpqrf9HgWVlDLDlzqTkP3SJGzh6JVHxsOG
dc9Tem2H6Wp9sqtxOVrnwAGno9DDvOv0Kr3+ottMjF685KbkBAMhxkwbR0Oa
hN7VmP7PnWsAdsqFjsZtmtt6rU47PHue2tGLKSr00i7pvV/e8LvNA1r852XD
GTusJQxv7fRNGIBpig6vW8Q1hAdYmMZiH5VYNTfXPATzyFo343ahMohrKF68
IpI9tWlvntAm5Go/7hBMElkRGLaI9NSEJBDaOUC3G5GwCYxDv7qhJZiMUia0
gCYhCsUrrdrQZEfFBPdhVqbdzvm8meGl8fHF8R3lhtVZ1PtbWcmpkiiztP/9
DOClyhu7DWbU7jImpizNIu7DYhnt7Bg29g/qJqd3F6pIrrXc54ynbiT1q/uM
YbXmgtb9gradNKXbHKM0qjK5A1lIJptL8PXaLGrStcyTGyAQUPZJdyauTncv
bMNWi/dn4RVAfzkTpO9E0m6B4/5P5rly5K60z6PdGG30Tt5dnFF+8AaDy+b+
8dkj2svwq/a5XAJJvCsuTvlqsroa4L9/8u3j29v4/mAs8yuy33F+VZkFvf4m
dhwSRXhfr4rn6QRS8uTxUcFzmhLTgr5SQVxZXYnzKUi/sEt3pStW+ktUd1j3
b2RsshuY0RYxNmfcDLIOPjdI/gsSDAFiACEAAA==

-->

</rfc>
