<?xml version="1.0" encoding="us-ascii"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.6 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC7252 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml">
<!ENTITY RFC7641 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7641.xml">
<!ENTITY RFC8040 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml">
<!ENTITY RFC7049 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7049.xml">
<!ENTITY RFC8132 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8132.xml">
<!ENTITY RFC8071 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8071.xml">
<!ENTITY I-D.ietf-core-yang-cbor SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-core-yang-cbor.xml">
<!ENTITY I-D.ietf-core-coap-pubsub SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-core-coap-pubsub.xml">
<!ENTITY I-D.ietf-core-comi SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-core-comi.xml">
<!ENTITY I-D.ietf-core-coap-tcp-tls SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-core-coap-tcp-tls.xml">
<!ENTITY I-D.ietf-netconf-subscribed-notifications SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-subscribed-notifications.xml">
<!ENTITY I-D.ietf-netconf-yang-push SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-yang-push.xml">
<!ENTITY I-D.ietf-core-sid SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-core-sid.xml">
<!ENTITY I-D.vanderstok-ace-coap-est SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.vanderstok-ace-coap-est.xml">
<!ENTITY I-D.ietf-anima-bootstrapping-keyinfra SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-anima-bootstrapping-keyinfra.xml">
<!ENTITY I-D.ietf-netconf-zerotouch SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netconf-zerotouch.xml">
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes"?>

<rfc ipr="trust200902" docName="draft-birkholz-yang-push-coap-problemstatement-00" category="info">

  <front>
    <title abbrev="CoMI Push">YANG Push Operations for CoMI</title>

    <author initials="H." surname="Birkholz" fullname="Henk Birkholz">
      <organization abbrev="Fraunhofer SIT">Fraunhofer SIT</organization>
      <address>
        <postal>
          <street>Rheinstrasse 75</street>
          <city>Darmstadt</city>
          <code>64295</code>
          <country>Germany</country>
        </postal>
        <email>henk.birkholz@sit.fraunhofer.de</email>
      </address>
    </author>
    <author initials="T." surname="Zhou" fullname="Tianran Zhou">
      <organization abbrev="Huawei">Huawei</organization>
      <address>
        <postal>
          <street>156 Beiqing Rd.</street>
          <city>Beijing</city>
          <region>Haidian District</region>
          <country>China</country>
        </postal>
        <email>zhoutianran@huawei.com</email>
      </address>
    </author>
    <author initials="X." surname="Liu" fullname="Xufeng Liu">
      <organization abbrev="Jabil">Jabil</organization>
      <address>
        <postal>
          <street>8281 Greensboro Drive, Suite 200</street>
          <region>McLean VA</region>
          <code>22102</code>
          <country>USA</country>
        </postal>
        <email>Xufeng_Liu@jabil.com</email>
      </address>
    </author>
    <author initials="E." surname="Voit" fullname="Eric Voit">
      <organization>Cisco Systems</organization>
      <address>
        <email>evoit@cisco.com</email>
      </address>
    </author>

    <date year="2017" month="October" day="18"/>

    <area>security</area>
    <workgroup>SACM Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document provides a problem statement, derives an initial gap analysis and
illustrates a first set of solution approaches in regard to augmenting YANG
data stores based on the CoAP Management Interface with YANG Push
capabilities. A binary transfer mechanism for YANG Subscribed Notifications
addresses both the requirements of constrained-node networks and the need for
semantic interoperability via self-descriptiveness of the corresponding data in
motion.</t>



    </abstract>


  </front>

  <middle>


<section anchor="context-of-the-problem" title="Context of the Problem">

<t>A binary transfer capability for YANG Subscribed Notifications <xref target="I-D.ietf-netconf-subscribed-notifications"/>
based on YANG Push <xref target="I-D.ietf-netconf-yang-push"/> can be realized by using existing RFC and I-D
work as building blocks. This section is intended to provide a corresponding
overview of the existing ecosystem in order to identify gaps and therefore
provide a problem statement.</t>

<section anchor="binary-yang-transfer-protocol" title="Binary YANG transfer protocol">

<t>The CoAP Management Interface I-D (CoMI <xref target="I-D.ietf-core-comi"/>) defines operations for a
YANG data store based on the Constrained Application Protocol (CoAP <xref target="RFC7252"/>).
CoAP uses a request/response interaction model that is based on HTTP (similar
to RESTCONF <xref target="RFC8040"/>) and allows for multiple transports, including UDP or
TCP (see <xref target="I-D.ietf-core-coap-tcp-tls"/>). The Concise Binary Object Representation (CBOR
<xref target="RFC7049"/>) is used for the serialization of data in motion in respect to CoAP
operations and the data modeled with YANG <xref target="I-D.ietf-core-yang-cbor"/>.</t>

</section>
<section anchor="device-type-scope" title="Device-Type Scope">

<t><xref target="I-D.ietf-core-comi"/> states that CoAP "is designed for Machine to Machine (M2M)
applications such as smart energy, smart city and building control. Constrained
devices need to be managed in an automatic fashion to handle the large
quantities of devices that are expected in future installations. Messages
between devices need to be as small and infrequent as possible. The
implementation complexity and runtime resources need to be as small as
possible."</t>

<t>In addition, <xref target="I-D.ietf-core-comi"/> highlights that "CoMI and RESTCONF are intended to work
in a stateless client-server fashion. They use a single round-trip to complete a
single editing transaction, where NETCONF needs up to 10 round trips. To promote
small messages, CoMI uses a YANG to CBOR mapping <xref target="I-D.ietf-core-yang-cbor"/> and numeric
identifiers <xref target="I-D.ietf-core-sid"/> to minimize CBOR payloads and URI length."</t>

<t>In essence, via CoMI, a small sensor can emit a set of measurements as binary
encoded YANG notifications, which would only add a minimal overhead to the data
in motion, but would increase interoperability significantly due to the powerful
and widely used semantics enabled by YANG (in contrast to a set of raw values
that always require additional context information and imperative guidance to be
managed and post-processed appropriately).</t>

</section>
<section anchor="subscriptions-via-coap" title="Subscriptions via CoAP">

<t>The CoAP pub/sub I-D defines a CoAP Subscribe operation <xref target="I-D.ietf-core-coap-pubsub"/> that is
based on observing resources via the Observe option for the GET operation as
defined in <xref target="RFC7641"/>. The CoAP pub/sub draft is intended to provide the
capabilities and characteristics of MQTT via a CoAP based protocol. The only
other CoAP operation that supports the Observe option is the FETCH operation
defined in <xref target="RFC8132"/>.</t>

<t>The Observe option creates a small corresponding state on the server side that
eliminates the need for continuous polling of a resource via subsequent
requests. Instead, subsequent responses including both the Observe option and
using the token of the request that initiated the observation are returned when
the observed resource changes. A subscription (i.e. the observe state retained
on the server) can be discarded by the client by sending a correspond CoAP GET
with Observe using an Observe parameter of 1 or simply by "forgeting" the
observation and return a CoAP Reset after receiving a notification in the
context of the subscription. A subscription can also be discarded by the server
by sending a corresponding response that does not contain an Observe option.</t>

<t>The subscription used in CoAP pub/sub are used to subscribe to a topic provided
by a CoAP broker REST API. YANG Push <xref target="I-D.ietf-netconf-yang-push"/> and corresponding YANG
Subscribed Notifications are used to subscribe to data node updates provided by
a YANG management interface. YANG subscriptions can include a filter expression
(either a subtree expression or an XPATH expression). The encoding rules
of XPATH expressions in CBOR are covered by <xref target="I-D.ietf-core-yang-cbor"/>.</t>

</section>
<section anchor="configured-subscriptions-and-call-home" title="Configured Subscriptions and Call-Home">

<t>Configured subscriptions are basically static configuration that creates
subscription state on the YANG data store when it is started and persists
between boot-cycles without the need of a client to create that subscription
state. In consequence, a configured subscription can result in unsolicited
pushed notifications in respect to a YANG client.</t>

<t>A popular variant of the configured subscription as defined in <xref target="I-D.ietf-netconf-yang-push"/> is
the Call Home procedure defined in <xref target="RFC8071"/>. In this approach, a Transport
Layer application association with the YANG client is initiated by the YANG
data store. After this "initial phase, in which the YANG server is acting like
a client", the existing Transport Layer connection (or session, in case of, for
example, TLS) is then used to the YANG client to initiate a subscription (i.e.
the YANG client is initiating a dynamic subscription based on a pre-configured
request retained and issued by the YANG data store).</t>

</section>
<section anchor="bootstrapping-of-drop-shipped-pledges" title="Bootstrapping of Drop-Shipped Pledges">

<t><xref target="I-D.ietf-anima-bootstrapping-keyinfra"/> highlights that effectively "to literally 'pull yourself up by the
bootstraps' is an impossible action. Similarly, the secure establishment of a
key infrastructure without external help is also an impossibility."</t>

<t>According to <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/> the bootstrapping approach Call-Home has problems and
limitations, which (amongst others) the draft itself is trying to address:</t>

<t><list style="symbols">
  <t>the pledge requires realtime connectivity to the vendor service</t>
  <t>the domain identity is exposed to the vendor service (this is a
privacy concern)</t>
  <t>the vendor is responsible for making the authorization decisions
(this is a liability concern)</t>
</list></t>

<t>A Pledge in the context of <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/> is "the prospective device, which has
an identity installed by a third-party (e.g., vendor, manufacturer or
integrator)."</t>

<t>A Pledge can be "drop-shipped", which refers to "the physical distribution of
equipment containing the 'factory default' configuration to a final destination.
In zero-touch scenarios there is no staging or pre-configuration during
drop-ship."</t>

<t>In the scope of Call-Home as a part of YANG Push, either the factory default
configuration of a drop-shipped Pledge that is a YANG data store would require
to include the "home to Call Home" configuration or it has to be configured
locally.</t>

<t><xref target="I-D.ietf-netconf-zerotouch"/> is intended to provide more flexibility to the Call-Home
procedure already - by allowing to stage connection attempts to a locally
administered network and if that fails fall back to connecting to a remotely
administered network. Alas, <xref target="I-D.ietf-netconf-zerotouch"/> is either prone to the same
limitations as cited above or requires local configuration in order to find the
home to Call-Home.</t>

<t>The "Join Registrar" defined by <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/> mitigates the cited problems and
limitation by introducing "a representative of the domain that is configured,
perhaps autonomically, to decide whether a new device is allowed to join the
domain. The administrator of the domain interfaces with a Join Registrar (and
Coordinator) to control this process. Typically a Join Registrar is "inside"
its domain."</t>

</section>
</section>
<section anchor="summary-of-the-problem-statement" title="Summary of the Problem Statement">

<t>Currently, the following gaps are identified:</t>

<t><list style="symbols">
  <t>no CoAP Subscribe procedure for dynamic YANG subscriptions is standardized
that is able to convey a filter expression and potentially other metadata
required in the context of a YANG Subscribed Notifications application
association. Analogously, new payload types (e.g. a FETCH payload media-type)
have to be defined.</t>
  <t>no CoAP Call Home feature is standardized to support a popular variant of
configured YANG subscriptions.</t>
  <t>no general Call Home mechanism is standardized that enables the discovery
of "a home to Call Home" or that would be able to deal with "changing homes"
in a dynamic but secure manner.</t>
</list></t>

<t>In addition to the identified gaps, the semantics of metadata - if there are any
- that have to be conveyed to or from a YANG data store in order to subscribe to
a (filtered) YANG module or data node are not identified.</t>

<t>The problem statement could be summarized as follows:</t>

<t>"There is no complete solution based on CoAP to enable a freshly unpacked YANG
data store ("drop-shipped pledge", e.g. the cliche light bulb) to discover an
appropriate home it can than Call-Home to in a secure and trusted manner in order
to push (un-)solicited subscribed notifications."</t>

</section>
<section anchor="potential-approaches-and-solutions" title="Potential Approaches and Solutions">

<t>There are multiple approaches that could lead to viable solutions that address
the identified gaps. The following sections illustrate the general solution
context and some of the most promising approaches.</t>

<section anchor="yang-subscription-variants" title="YANG subscription variants">

<t>A YANG Push update subscription service both provides support for dynamic
subscription (i.e. subscription state created by a client request, allowing for
solicited push notifications in the context of an up-time cycle of the server)
and configured subscription (i.e. subscription configuration retained on the
server, allowing for unsolicited push notifications across up-time cycles of the
server).</t>

</section>
<section anchor="yang-push-via-coap" title="YANG Push via CoAP">

<t>The two CoAP operations that enable a subscription mechanism are GET and FETCH
(i.e. by supporting the Observe option). Both operations are viable candidates
for creating a CoAP-based YANG Push mechanism for CoMI.</t>

</section>
<section anchor="dynamic-subscriptions" title="Dynamic Subscriptions">

<t>Using CoAP, the client issuing the initial subscription request creates the
subscription state. Examples are the GET or FETCH operation including an Observe
option using an Observe parameter of 0 (zero).</t>

<section anchor="yang-push-via-get" title="YANG Push via GET">

<t>This usage scenario requires two consecutive operations. It is not possible to
transfer a filter expression included in a GET operation. In consequence, a POST
operation on a collection resource has to be conducted in order to convey a
filter expression to the YANG data store, allowing it to return an URI that
contains the data node information filtered in respect to the posted filter
expression (encoded in CBOR).</t>

<t>This variant allows for multiple clients to observe a specific filtered data
node without conducting a POST operation, if the corresponding URI is made
known to other clients that did not conduct the POST operation or, for example,
is canonically linked to/derivable from a filter expression.</t>

</section>
<section anchor="yang-push-via-fetch" title="YANG Push via FETCH">

<t>This usage scenario requires only one operation. A FETCH operation can include a
body that is capable to contain a filter expression and potentially other
metadata that might be required to establish a suitable subscription state on
the YANG data store.</t>

<t>It might be possible that this variant could introduce a slight delay in respect
to response time if providing a filtered resource requires a lot of computation
time on a constrained device. I.e. the resource cannot be prepared "beforehand".</t>

</section>
</section>
<section anchor="configured-subscriptions" title="Configured Subscriptions">

<t>Using CoAP, the server retains configuration that creates subscription state
when the YANG data store is started. The client has to have or gain knowledge of
the CoAP tokens that are included in the responses created in the context of the
subscription state create from server configuration.</t>

<section anchor="retaining-the-content-of-a-get-operation-as-configuration" title="Retaining the Content of a GET Operation as Configuration">

<t>This usage scenario "mimics" the receiving of a subscription request by storing
the corresponding information that are relevant for creating a subscription
state as configuration on the YANG data store. I.e. the configuration would be
including the YANG client IP address and the CoAP token to be used in the
responses that convey the subscribed notifications.</t>

<t>This variant requires that the client also knows or gains knowledge of the
corresponding CoAP token in order to not discard the incoming responses.</t>

</section>
<section anchor="call-home-via-coap" title="Call Home via CoAP">

<t>This usage scenario defines the Call Home procedure standardized in <xref target="RFC8071"/>
as an additional capability of CoAP. DTLS or TLS state is initiated by the YANG
data store and triggers a dynamic subscription procedure of the YANG client
using the session initiated by the YANG data store.</t>

</section>
<section anchor="dynamic-home-discovery" title="Dynamic Home Discovery">

<t>This usage scenario is based on the Bootstrapping Remote Secure Key
Infrastructures I-D <xref target="I-D.ietf-anima-bootstrapping-keyinfra"/> and EST over secure CoAP I-D <xref target="I-D.vanderstok-ace-coap-est"/> and
requires the standardization of a general use of Join Registrars in the context
of YANG data stores that support YANG Push via static subscriptions.</t>

</section>
</section>
</section>
<section anchor="iana-considerations" title="IANA considerations">

<t>This document includes no requests to IANA, but solutions drafts incubated via
this document might.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>This document includes no security considerations, but solution drafts incubated
via this document will.</t>

</section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>Carsten Bormann, Klaus Hartke, Michel Veillette</t>

</section>
<section anchor="change-log" title="Change Log">

<t>First version -00</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>

&RFC7252;
&RFC7641;
&RFC8040;
&RFC7049;
&RFC8132;
&RFC8071;
&I-D.ietf-core-yang-cbor;
&I-D.ietf-core-coap-pubsub;
&I-D.ietf-core-comi;
&I-D.ietf-core-coap-tcp-tls;
&I-D.ietf-netconf-subscribed-notifications;
&I-D.ietf-netconf-yang-push;
&I-D.ietf-core-sid;
&I-D.vanderstok-ace-coap-est;
&I-D.ietf-anima-bootstrapping-keyinfra;
&I-D.ietf-netconf-zerotouch;


    </references>




  </back>

<!-- ##markdown-source:
H4sIAENw51kAA41bXXfbNpO+x6/AUS9i75FUJ9tPX9Vx0sZvkyZru93u3uyB
SEhCTRIqQdpVe/Lf95kZgAQlpW8v0toSCQzm45lnZuDFYqE611X2Uv/P1U8/
6A992Or3O9uazvkm6LVv9bV/d6PMatXax0v+hZ9SpS8aU+PFsjXrbrFy7cPW
V38u9qbZLHZ4YlF4s1vsWr+qbB0609naNt3i4kKV+PlSv7h4/vXi+cXi+TdK
uV17qbu2D92Li4tvL14o01pzqYMt+tZ1e/W0udR3V9fv9H/79sE1G/1D6/ud
eni61DdNZ9vGdotXJIcqTHepXbP2WqnCl3j2UvdhYULhnNq5S6W17nxxqfc2
0M/Bt11r12H8YF9Pfi98TXLHD5Tpu61vL9UCm+CzN0v9Mp4cD4tC3tjmIf/U
t5Dh+9b0zdavbavvbu7xadLo0Re2Nq661Fusskxa/S64brkenlyWFg8GCG5x
2tuthSxda0Kw+usvFclcQo5nX33x4tsvn9Hv0OGlfmVaskPZ8RN907X48Afb
1qbZp/PcL/X/bn0/nOXemaY1TfqQj/KmN0/WZUcYPoii/4mHO3nxuy1/t4QW
M4mff/mVfmnd72TJ23KJb1q7gcNhKeNKvKlfOTzrim4QHo//hsdz0a+3rjFJ
8F+X+q0b5f61X1ssLh+x1P8yK1dlQqffo8zywv/hhe9+o28OJP7mxTfP4XTW
NmHlW69fte7RzvVd7zoLT77IjvCueGtxgl+uBkO8ePEcLp1J/vPdVZL79VL/
4l03CP4ap06fsNzXLhRe3+0D4ieM8tpHPPNdQV+yqKrxMGQHqcjFb7+//vrF
ly/Sj1998Tz++M3FFxfp04svvk2fPv/PF8MDX/OzN4tXS2e7NaK4tRLUBU6O
KMCP9NPRMxLu/Sr0q0st/z/xTO0uKaTc6de7Av8qqKW1lTMAjvwxBHnhm/UC
C4eidStbLhrfubUrBK1ENnx08q0Bl+Qx+ulIhuBKgI4r4xePpiltGzr/sDBF
lNAGeMPru3v+LeQrmMbVZrHyvqNY3O3grYsHuwcWtYCyl7d3P96ckutP2/rO
90WUa/gVoAgUG2yqFosFfJeWRlSo+60LGhDcEzZpgOyjK23QRke81QPgzjXO
gCXwZQOXcwjMSm/MDr+aah8cfV4qV1U9rd3xImuHUwN9O+3XQMiqJ/1qnKn1
ptjiEdeQu5u2BJZq029oIwpmSiIE7wb7Q6FBr0ywpcbL3dYieVx90O+w74Yl
E+heQ7X6yXXbMQMBxHcUg5DVhqW+0isEertHgjBNIKCsbbGFukPNCYrfuxuc
Qv+UO4UyZQlBAsnisQnJ0drfe9eyDIFOCDvQ2V3DHlVaDds8IdGwaviNxmJd
7KUCwg9HLaAByO4pU7Kge/3ocGhbrRewAwTZkdkabEwb0BJwMMix8w3lJM06
co2qPUm5FPPWrizh8uozaArL/9Gldz+IUZU6VsWgqv2/14X+669FCpGPH9Vg
mzH1xwcoOD5+xNqNXpG6TOX+xKOrPVIpSW//ADwzeH9/zTqCVyvSmDZQc+8q
PuOq8sUD7Me+ilTOTuQCqw6Bxb4TPRc+N9GP8o+2fXT2KWlg2NEWPjAWkg/6
Fr5Ny2AJWGW9J8cerIY0Dh9U4xZHsQG9f/YZUjWrlLUw6HVHYVj4ikLt7zwX
J9dnzIqgOwK2jx/PEXFrOBNMP2VSRvEeY3wchsfghvpqt6ui2cj6LArtAzH+
+iuiO3ZaKv6oDxy25NfAp89FjyAD7KRGFF/DsSvsYzqywbDxm/v7D/osuNpV
plVQ5S3A7fr9T9/LPpQv6ESkUlNV/klOUvdV53aVFX3twKHCHLsVVc+W//nV
B9hG3V/T0taSahKgk9BaVNoge9mk/fer3+Ah+tbuID1ULEc/u375/lbJiZGu
SBII3weJRtZaALqRf8oLcJcYWlpCS6Aq7GhxnI7UpTKzpADnl1hFWHpEoxgP
lO8+fhRveWUfHZLB/X5n9V2BpZQaLC+eFUTLbJkZwbQNbtNEkd8BQGFhkiX9
ePbuxbtzZUaLI1qQACiWQm3aTgNH2s1+Hn8jPsRyD4EG/OpaXy1zD1IlyxkE
urAbArlmBy5JJYhsMFlP2aXQaxO2pCo8BVgtyaxQCfxhY9XvPeEdATHrNi7K
BwRHR1ySZmXNdd/1LTkdtFBVcpKlfgcMxK5BrQCq4E/6hGBy0qriY1HCJEdG
mOHznQ/BwW/YaZSr4XT14B7QOn7/IymkBb1yNQFW8H37yT2CGhadKXUDTZSl
o/XmYwzrrdtsK/zr4mFnHOO0yxAgprUTLCMAVKRbcYOKwL+oHBU9cFIAWlI0
n4WwlECJABUaRz3TlAtw3h0tJQcDtTQqfm9JRNiaA05Ceq6fCOT0T69FHjos
goMXeH4hK2pakTCYobYmbiRaqKNZ5lLSRQQRDESYIOzgLkxipkHAKmhAO8BT
VYRdB5JET4E54QG8XoNn1EgZss7O7CtvSgm2n29vdAWm3W2j8ik3NwW4NCVQ
kmVOSmEZ8QXKM05DtnYdfS6UpLYm9CmBU8phDFFYx5Mt+BQTakiqcgipJ99X
BHvVnoyOBVlSECLKN1tr2I4JD9QAInPEWhdfBsohISZwzRkARTlv2XRYv+xt
Wmznn5At+kqRAp6gtGovGJbYRECIEzhyimXpz1wjYW0C49Zw9NY86UdTAeeV
BGH1ZPYhUZrBlXGkInKIgUYShaP4qgX+Hq3e9K40UL6EiEr4QE8hRDoq3guy
TyncbwekhV/vzwUJI83YCWSJ+YCuY8JEEfA5yDrnyJQS5aGRoow5kjxIygZy
IslTI0fxK4ohcscxumlL0u97/o6W4nVSZvjh9X22OsJeZGCskpSCugiwro8E
5pbGp6gKlp4QVFYX+CglWkRFYHvCUu/+6/6eRYxHlqMkXiG7kicqT1xFnhnF
ZQWEfse59dQpnXz6PYL/zfje0RmptOPUdX+8BDmyEH6JtylFZRBL3CQCWBAF
mE4hnSN2YrYbCTJ7nWt63xN0VxUtBF2YwWrCk2FmgXgVOQsg6gZ5AxE4z77V
icmEjFwMNP7gNFTGCD2lL1G02Saxx7hJ9CqugShn0VfiV9FFWnoUSYwUCGxt
1PgEPhmOQMXHRiqTkMUAgnaJPJW9E3WINSUnT5R5nvh1iSIepZREP5cKnDTo
NyAgnzmnx+IpcG7FPCVpQY6OFdMHO3hkjRzSkhaeg4/Besgqe1p3BlNtLCWU
GfvzRAuUSVkLyXNvLYEPQgJrtbaw7lFkyiGWHI4jY1q55Po50hed31TBn1SC
KEl9QgkRCITmsllLT/ned+yBRijO1ENiEExEYBjGw5PwJz/gLxD1Q7NBULjz
OxCmCAUlSZeiu4XDtUwO9NWHm+UniypGi8k5uGj+ZM32SWGYsnK52u9KDsQk
FlSoYi6vx5rFpZolyhYm8F1wd4BizHIDoCJjg91R7Uy4cmYdwxQHLzXFsi/J
t/D6rx+u7t9kH0eiz1mZ7dWDEik4xuGD3E9gqkCHLSgXix+coN+guGu36emB
af4hvV4DxRZvfA1Onj03PaiRsgv6rRALFKAwaBGfzrA3gqOauMsEEw+LOUIM
7Thv4Lm2S5kU7AhZYSTA1CJaFPsC2uBSw/fdiKEMlhEAiAiyFCkbjJIoloRA
k7sXDJdEosxwlIODs4GhbxRupO0ezArlhoOQihwTT08I00HZFL1J5FpSH2Ln
dz0qBHARkIKmG7scp3c3QU8yUx4RLjDOkvE0GU8z7SipljjKZhdfc8a+IQtQ
6yq2pOjg96kUVW/Nnjw1K6FNCL5w8jOj5mC/qGrO9SkvRAQ6aGYBvhgBeeNZ
6qTttkjrVPtGhjksHDMmCVkwc6/cg1XJtrP5tK0xCK9FeOixiR2TM0JuCRTe
pyDy6ddz7kfZPwxVCnN9//buPHKCZsCLw1NSpySeUgL5IHepT6tFALjcN6ZG
vExeHTgadVioTZpcICX3IQEK/wyhnyo5C6JILV/mXVTyrVdgn4u7rdvt8OoH
MGWqKKnw5r7qiXrNrtekv0fi2jOcG1wNFIlC/hkct9J7pHJq11G9JKKooXUb
nrHZGqLKsVLUUnIt9Z10Sqr9PGapgvwUhwR/d2HLSEsxrB5Q4XHvF0v2BVfG
KdiRH21LFH1rqx1vRUkw24/rCaqPrgqkCgZPHCE7LW096TQPkTBiIGr5kFpe
0uQlytZNC6IzU/tmAxMxCQ3nUvwI/e1YP+RT7T6KEJupl0r9h1Q2bIlUfQRu
FXIJnvz3kQqj6ImPyOPsyy01AOIKpa8pWUsliWexHRKDzxx4+po+4/gjpSmN
47lHU+xpuwIqPY+LxldcSByBTciNK/OQGKJM8lLjqLSF41yEVcctNDWtpLob
tgD4iQNGyqMzypOZiECCVdR6hlGqt6T1kXQP+yiTH10aJxIbVNm4tlyAxeGr
M7vcLOfxXHPK6j0yOTlVS402Su0bJC/fnrPXJAEjwZyVFD1BomeWtm/tmup2
aFnk3O45KRIT68Ax+thPU2TbHft1ZFZJgc9IBN/uCaUN8sqzwzTqmUmQo5eW
YM4ICwN405RjwWMOHQrUvq3zQVq2pLfGUwLdcOi3E0yJtupb6hEPp4qdBI5H
6siRJcYwMDwWoc4ZPh5Y2VxHQkNvHRxETbfjlJyrMKk3NVPNMRXgVkEMC8Ww
K9SKdpttSSzqsqSMNzvQHPlux/ErvasMUivPxGXJ4DcZGInPnapYaxJpTY2y
6Msxska6NGZcUyGGy71esBNSxzeGPlnE5nnJdJ2td10QO0e5lCmppYJKjihA
nKMI7K9FX2vjqoD/4ugrUzxIt0sWjRgDvVGj6hOLIQ1XJsz16eNHo+I8zdB+
CSiDcuwjj2Dmo83KU3XQjgDGxziwRj5ogDtz3ahyG7IOY3Ux+5fH87d2Q1Fk
2tlAYYTOJnSAMG4zVM8izSewmt501OAt+4JUNCMFjV3yR5u4V4TS5JWj08wV
OOiWJyN95xtfC/mdcxUB3CuZu0Z639iniFOSmeAB4k2/+VjiyT5C7pOFGHwO
BBkKDqG5WHuqGyQfHPTac4Zj8IrOQM1soVmxAYW99rvI2I9WETZGnYmZQs6K
uxMmUIuqrmm6MJ2j6bs0AEKd0KMUo4ad5PO1Ty4vkyQCpNTkLDntNf6wgzUG
D2WYRJFO1FhSGDQl6lyapyHTDAhC+UkO/2j3pwqw2JTrSBbWg3SNUOAb7lXq
5MPlibRk/s1cMKPKdENiJMsINsC33/g+kIbIN2I3V3f7HQzLiQnrSxsqfVfb
0pkFPXGO9bbmMXYYUzAsMz2OtH+NUqeXDJCrSQpfboQRkB/VHXyxYqg6jtUe
N9vQFAWxPe43TpGPdmQGyS1ZCVDqTlBZuqdbGWsKwRMYzm1Hk/rENHKIVi3B
iiQEZtw6Ivei98MMy/HAIDkNtZkjpUSOh8DLyYAiIdrokuymiYqmZjJ3yMUv
gOMMvJRZyZnlqg+LmZlF3E5UjVOsW1+fSGo5DuadCBQ1Z+KvtjyPbQeAVcXI
OnYpaHvqz4zCR8g8GsvSRRnRYOD4ZZuYEIOT2OfsPuMKw7BkuKkwVCTsYRBX
bElxhXDaUvu92SH5RH/Jijx9NiFLkeCCM7Gfx+ZcQdMxqjVgr2rFqJUcBApW
Wa9c3AS5nJgYtN5kvIRZATf22d48iaQbcNhVbD8onAgE1cr6rG8W50PhPhrh
oHgX7PuQwIKGyeniBu1yF9UUWP3RMYaJbnbLQ/ogbIsqzkYeeYg7aDpNAqUs
UCd8U9LECKvxHgDAcLhxwmpN4ZlWHhqJJHEgfUUMr33gCy+1C3ndY4NUjkfx
n5AiEC8em3LSM5s+mUoM7jAPd2oS9mTgrk60fU/0iaR5E+l8rKhjSTwfuRVf
KxlsynY+asUc4jlK/N1CCi3qIw3dVmksK+kxnu7EnJB2SneGYl3aXEoWnQqc
949OiWwKVD1hKmS6CRMXPM/sxRaZDpDA9Q5GIiGH5cP2xYjl5Mw0+SEdcFZS
cmJqJIslU/0y7Q6fL/VLsnt+OaC1yeERv6XjLqviKQdZVloiJORCAGc8y/SC
Ek014+WBiPOT1qVSP7Mr00rzfABAnZIkbOo3TU6d+itpkMPaPfLDpX4tXSI5
0TAaaw+HR9mQZWyeK5865X83X7jQZ8TExaiHVqVZhdxY62nmPJR8I+0ma3Mf
s+iF0Q5GWOqbTnC+G+4CUM4ZLuqc4kqx2pKbDtM54KmW6Yf3d/fjpRDpZBVA
rFjoDHOfSUEGNh7vPQxJMbE3dSxR3owbs00WVI67c2nu0vCcnAdtsegO4zUV
zqb5VDcl34OmrYyeOaHIEyoT6CwNy2Pr/XwZTZSI1anbPuKXrIQ04cJJsB+F
/igGE1KWMnW8or4kYkjdo0HmkaAcDEXo/JCmNqVVD41/YhUK5x2k4LGPK9PU
h3YQmj/ZQFPHhI6ReqXK8bjDN7GiqFzzwNznc74pyfEeKdCRIU/6t8DM33s4
3zmgojTzxKujAJxMYdTKl/uxnKOR81AlyITrn5YJaqCDvFot3MWOJQNRpNTC
ZGh1neT5U8MPdcKTiadmC4+RSvt1uV8V8RaFFLTsQMKlSluZfebCiuMhjfgo
jcBRJCuLHw3+NgTooG3qR3RytbPe9VJHK14jBvd4005qXcBCmt2OY16wMC/H
QcFtaKfZiu8U0i2p2d/Po45BPQ4EJL2Gw15ZNnI6oXXFs6VTQ6dx2CRMK6aO
CFXM8eH6G3IXCiNpXKFoGu7j8qA8u9GVY2dURxzBJzpzzEdO5500vOJYiqef
nDoG063Nu4p89TU20Rm632dXOAZ1i0VPhtysdkixYRalT+NqXu9k9iRmAF1S
S/EYh3KcHXTU2so+kjMfcIHjCR33mqa9vZN2zPxv+ngqJtWYmw+HNDcfEgEf
rjOOlo0JK825yVKjRSPB56yVTeuPC4qD3DDmbQnvwe14kEF+FpLXhYnbxSsC
uYIzUfNcSpEX7wRE/kMX87Kpf4jeM9bzOYE8dot0AelTo8ZJA2A6b1SGp0H5
3arx1jX1mrHpUr+6f3tHp6b/ie3/wVAxln1us6Fe/CcGbKOQkedn1s+uvISB
/ZzYc4rVn2VclPXwamhwnFSeO7jJP53P3XK/Vt9JIfuj3aubyeAr8A2wrPtJ
h6aLElwxx/qX/SA+N/x9hTyrMn/LDZW151P52PNs9KBFeFhCqTQIyP9SIb9w
dZDf4yWBg64SSmx9c/XTFWcTVIqRsB7+bUbEU+5UpMtO5OD0qtwrHItpHrzx
Xad+xQbE7qqbLMcpVja/i38dx9d+/5kA6Q/qDmSeynEkhpKLdvmiTyjfRYqr
Yghwvo+p1DU0DgiHk9CfloHg/ViZPug3yFIPoLzvqH9S6V8slrBdx3/voK/5
SpV+6zdKfc9/ffJI1yYgDP3BIP91BE0L1P8DMnkwzrE4AAA=

-->

</rfc>

