<?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.27 (Ruby 3.3.6) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-zheng-ccamp-client-tunnel-yang-16" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.28.1 -->
  <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-16"/>
    <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="2025" month="April" 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 87?>

<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 93?>

<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>A YANG Data Model for Optical Transport Network (OTN) Tunnels and Label Switched Paths</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="3" month="December" 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-22"/>
        </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 291?>

<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="" surname="To-Be-Added" fullname="To-Be-Added">
        <organization/>
        <address>
          <email>To-Be-Added</email>
        </address>
      </contact>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA8VZW3PbxhV+x6/YwC9yK1C+JKnLNLUoWbI1tWWPxYmTXh6W
wJLcCsQiuwtRjKP+9n7n7IIERNKXmc6UM7ZI7NlzvyPLssRrX6qhSEfil9Hl
S/FCeinemEKVYmqsOC21qnxWypWyYtxUlSrTRE4mVt3gTjiNz8N9vpomufRq
ZuxqKJwvkqQweSUXIFNYOfXZb3NVzbI8l4s6ywMFzziylcTB4+8T10wW2jlt
Kr+qce/ibHwuxAMhS2dAWFeFqhX+q3x6KFJVaG+sliX9uBid4A94Ty/ej8/T
pGoWE2WHSQGWhkluKqcq17ih8LZRCcR4mkirJLC+N43X1SxNlsZez6xpapLR
LBamEqfgxJpSyKoQb5R0jVULkv1dKSuVJtdqhUvFMBGZqNStFzNVKSs9BKBH
TaVzY/mrq6W9LkFGFNp5qyeNV4UoVTFTNrlRVQMmhfg66kIELaUfwDihfknX
6flC6hLPWdXHWvnpwNgZHUibz3Ew9752w6MjgqNH+kYNWrAjenA0sWbp1BFj
OKKbM+3nzYSM4GVpJo3TR8rPM6+iDQmmhK6d7+Bfww7C9YE2/VtHX+IZg7lf
AH8iGz83lvSU4Z8QwbdO5xLOJ35p+BkEGIpXjVwqLcYqn1emNDOtHB+qoJdV
k/Od4znDDXKzuIfzlTQLLSvxd+Lr83hhUKUg96vHhy3Mz7rUjThRujbiJ12W
cqYOxZWpZm4OvK/lteKbufYIlhd4PmtkxY+smsF9huIlHswKE+nn4Hcovnvy
9NmjZ/FBA+dYkfy6kl3xWJnzIMF+EUcaRyBiNuKdNx4eBvAuNklws8YcT9vT
HcguyM7iBIb+YiOwawzIN/bz+EtTTXQlfu6Y9nR0cTru4rltVgx1nEud+4HM
B3l1Hw0UCVPKjqisNGStiS5VX3fSkMut/r06zglmwSA7ePu5mULN4rXuMDcq
1VScIaT7DBLgAO7AIXY8o8eMkLJSSAXbXg3P6+P+jDqBHnZ//OTpfm1eKQvP
gk+WxvuOoS7Nte45kGPAwSQAHld0vss6SDm3Gtrt6PUK3g3f00Sl7MUcAw9W
0gR8mQP6cgfWl7pxqq6VONcmz00pv1gFs3hzMI0396tibLITlY2KQhVdDN3H
SWXsApn8Bok50dW08yvJskzICaJe5j5JRigpsnK1sR5FwFMVEdoJSXq8UTZW
0fbEG1Fbc6ORsmD+SuVAiiSQELDOlSMA7Z0IaXAgxEUl/Bz4OFPiqxIhNQoz
jUCglhTK5XAlVRyKJVItwxVqqitNxagD6ztVe0FVexDkWeiiQCwkD0AQRado
cq5ipJ6vExCc6FmF4raRNOF8tRFWrIWlZkNG1rYVlUtrVyxKgCA8YGU61Xlk
CSW88uVKyNwa5xh0J1NWOdNYUIRCx3NmKCqCdSCQZcYBcXZWzXSllIUE7e25
dGKiVBU0igOAT4yfExqu+OBnKVdcp33rnavM1SrX03AW6K6hmSpMNdf5nMxH
/OB4Ip0S47NtIx1CF6CpoLAGRCSr4uPHby6yF5xVUFGlC22UV3d3RG0HH4zK
HQqHAigg09vx5REh+nD19rKnj0OIfKO47boveCD8fE04FG3jq7ZiM4K7O1LG
btilM1vAsE/N3qFKUtWpsfTEVIUO9a91+arvK+SFxKNVvzbakvPDawLrcLhF
XSqPcDE164Hw3Gi1FFNrFqzuWtmWLEVIa+48tF0lTgccAGOOP5M33H0FXZD/
F9Q1BwfCdVmWfe4C04cCNS5IwfZE74ZaP1NdZ4Il35+f/unP3z0KtgNv0S9B
ppkRWervfPDc1ok2jhKNRv4X/QSpsBATuGRdlzrnjtQJdVsbx4g4ZcsdEkND
Egfvz67GYMwrO5W5AkvnjQV1uzAWfYz2kQxhWVOqusTIEG1O6kRwy7CfS09U
kUORaEIWlhNzo/aGMGVCvzY4niDJVSaqRfpWN5FMP/qXaMDgO8gTCOyim0OD
lpfomOipVUyA8BQoCdAm5SeHhEq9wCzEtv61UZ0YOkWO0qB1RvdBMDTr715f
cb0Zv4vm7KQrQfkRUsCjSIKWJ1Bu8/EDRK9d6BC+jPDS+GDDmJCdhnMjpnFz
ZmWNNCJLREGNqAEF2eZ8rgIbJwUJtlaIYt/16tbrlKxI0njXrRYTA041qyf4
L+OjhpdwRII0yqD3twGwGyz0vevnz+Hnz55+u/ZziGcjJi4VcCW0HUtWvFVT
mKSC/6FEiRNU22uFypj+8x8pKyX9VypwXBokzRJTlcA45hh2xKOqjm4/UcAW
FVHRrEBNACbB1C5TltiRK071rImj2wEGwyJbWu3Vw0DJmhRdPkQMWAIAedRD
pncV9YQKDSVsE3re0kGQmJpowFwEgcH1mzSJZ1GbOXcGXkJpNsR0+ocUWoSv
cNZhUelxqeQ0o1/Mwzt2rjkwuLVW8rlBmY15Ab+JpDu895sswFGVLDCjwgLc
QFACLeFFB+kwDUKelaWuHQx6kA4Gg/QhKaQqQg0nhkHdkeNgiCf3cCEuCTk4
T9zcLCv27c3CYN+uAVARbAxEDLUOrxbiP/gg/nKtM2l9AgdvaKHBdaY3YlLE
xBwqjrwaesX/85nbfB1yI/jHLLNL4WwecIQipaqiNjq0H+L3FugGiVwXzwX3
j36OiRXDuBuGx31QL2d8+rwPyiTiUYd64fz/kfoENl3qAoeIyGk7Hu0/Dqhb
oN/j3w6d3Tf6WE8v3j8XOz8NJP/+23vQJ1dfAX32VbjPvgo3hYjN5BJOfu/W
xBiEZ3UfvKlpB5RNSzl7vgucvDr5OBQPkI2CE8TmJaOQEry1+zHdBMNZbwtH
MEiNlqteRsnnx3Q7IAYMdrcjyMbrwcIQhRia4orrVQjZJOFmyCkeD0Jlnah1
sxXrwCbOTykNfirMqeqcjV/15KBLMcKppY3BvSO2xcdkPdWhuiLVpY2thgQ4
RLGVCze8XZTDyg0Jz3AbQfpDQIDMO9W3It3EXXuCQktzT2yyQbA1WXvFK4DS
g7vtC4wOlT+Ewo7LmzjpI8G8i0D+LW4S4ye9oIaM7N7OKFSqx9Jdi3OD4UYc
0L70oTg9Hb15Jz68ZJRcSvKQPdKI6sNL8VrTou4vNPd6M+wvCv+aRLiLF1mY
OsOmdbjmpLcfEwd7Nk4Pf1hf2CyIxMHOzU8Hdr2ZEgft8une5qQDvF4RiYNd
m6AuZLsFIn73bnk6FzYbHsK9Z4kT4VtvCS1v3TfbOPZ25MOb4WGxroDk/psJ
u+9+1MbQPlw8efT4WfboafbocceNdpGLnoK5n1vCcD3diLXuqvo3vmQR2/dR
XlaTB+4oVrt5FOk7CkrkCes2koek1ApMH2psYoXrIKIPhcp2vfuhB7NPKSzm
T69Hl1QRhS4GHaXc3SPeFsbPkO/W0L1MdIgSXJ9sh3jbpKSf6FLSLzH+KCIK
fVxR6Nhw1hvltwNza4Uegrid6Zlk3ZHua47uaeqTRrjiXUzH+qLF0qNJn4bb
2W1y93XY53FPC/U1PL5QDsNlmKT+V4zu4HSrO/oaHjt8rfGIFk+79WER9rLb
8WSfbTHjtl31rt+joJJSZvhcZxKyX5qELRy9zMh42LDux5ReyGG62pzsa1yO
NzlwwOko9DBvO71Kr7/oNhPjkxfclJxiIMSYaeNoSJPQ2xrT/4VzDcDOuNDR
uE1zW6/VaYdnz1M7ejFFhV7aFb3Ryxt+a3lEK/28bDhjh7WE4a2dvg0DME3R
4UWKuIHwAAvTWOyjEqsW5oaHYB5Z62bSLlQGcQ3Fi1dEsqc27fUT2oRcH8Yd
gkkiKwLDFpGemZAEQjsH6HYjEjaBcehXt7QEk1HKhBbQJESheKVVG5rsqJjg
PszKtNs5nzczvDQeXY7uKTeszqLe38hKzpREmaX97ycAr1Te2F0w43aXMTVl
aZZxHxbLaGfHsLV/ULc5vZVQRXKj5SFnPHUrqV89ZAzrNRe07pe07aQp3eYY
pVGVyR3IQjLZXoJv1mZRk65lntwAgYCyT7ozcXW6f2Ebtlq8PwuvAPrLmSB9
J5L2Cxz3fzLPlSN3pX0e7cZoo3f69vKc8oM3GFy294/PHtFehl+iL+QKSOJd
cXnGV5P11QD//ZNvH9/dxfcHE5lfk/1G+XVllvRim9hxSBThTbwqfkynkJIn
jw8KntOUmBb0tQriyupaXMxA+sSu3LWuWOkvUN1h3b+RscluYEZbxNiCcTPI
JvjcIPkvzH+4uNogAAA=

-->

</rfc>
