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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

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

<rfc ipr="trust200902" docName="draft-trammell-taps-post-sockets-03" category="info">

  <front>
    <title abbrev="Post Sockets">Post Sockets, An Abstract Programming Interface for the Transport Layer</title>

    <author initials="B." surname="Trammell" fullname="Brian Trammell">
      <organization>ETH Zurich</organization>
      <address>
        <postal>
          <street>Gloriastrasse 35</street>
          <city>8092 Zurich</city>
          <country>Switzerland</country>
        </postal>
        <email>ietf@trammell.ch</email>
      </address>
    </author>
    <author initials="C." surname="Perkins" fullname="Colin Perkins">
      <organization>University of Glasgow</organization>
      <address>
        <postal>
          <street>School of Computing Science</street>
          <city>Glasgow  G12 8QQ</city>
          <country>United Kingdom</country>
        </postal>
        <email>csp@csperkins.org</email>
      </address>
    </author>
    <author initials="T." surname="Pauly" fullname="Tommy Pauly">
      <organization>Apple Inc.</organization>
      <address>
        <postal>
          <street>1 Infinite Loop</street>
          <city>Cupertino, California 95014</city>
          <country>United States of America</country>
        </postal>
        <email>tpauly@apple.com</email>
      </address>
    </author>
    <author initials="M." surname="Kuehlewind" fullname="Mirja Kuehlewind">
      <organization>ETH Zurich</organization>
      <address>
        <postal>
          <street>Gloriastrasse 35</street>
          <city>8092 Zurich</city>
          <country>Switzerland</country>
        </postal>
        <email>mirja.kuehlewind@tik.ee.ethz.ch</email>
      </address>
    </author>
    <author initials="C." surname="Wood" fullname="Chris Wood">
      <organization>Apple Inc.</organization>
      <address>
        <postal>
          <street>1 Infinite Loop</street>
          <city>Cupertino, California 95014</city>
          <country>United States of America</country>
        </postal>
        <email>cawood@apple.com</email>
      </address>
    </author>

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

    <area>Transport</area>
    <workgroup>TAPS Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document describes Post Sockets, an asynchronous abstract programming
interface for the atomic transmission of messages in an inherently multipath
environment. Post replaces connections with long-lived associations between
endpoints, with the possibility to cache cryptographic state in order to
reduce amortized connection latency. We present this abstract interface as an
illustration of what is possible with present developments in transport
protocols when freed from the strictures of the current sockets API.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>The BSD Unix Sockets API’s SOCK_STREAM abstraction, by bringing network
sockets into the UNIX programming model, allowing anyone who knew how to write
programs that dealt with sequential-access files to also write network
applications, was a revolution in simplicity. It would not be an overstatement
to say that this simple API is the reason the Internet won the protocol wars
of the 1980s. SOCK_STREAM is tied to the Transmission Control Protocol (TCP),
specified in 1981 <xref target="RFC0793"/>. TCP has scaled remarkably well over the past
three and a half decades, but its total ubiquity has hidden an uncomfortable
fact: the network is not really a file, and stream abstractions are too
simplistic for many modern application programming models.</t>

<t>In the meantime, the nature of Internet access, and the variety of Internet
transport protocols, is evolving. The challenges that new protocols and access
paradigms present to the sockets API and to programming models based on them
inspire the design elements of a new approach.</t>

<t>Many end-user devices are connected to the Internet via multiple interfaces,
which suggests it is time to promote the paths by which two endpoints are
connected to each other to a first-order object. While implicit multipath
communication is available for these multihomed nodes in the present Internet
architecture with the Multipath TCP extension (MPTCP) <xref target="RFC6824"/>, MPTCP was
specifically designed to hide multipath communication from the application for
purposes of compatibility. Since many multihomed nodes are connected to the
Internet through access paths with widely different properties with respect to
bandwidth, latency and cost, adding explicit path control to MPTCP’s API would
be useful in many situations.</t>

<t>Another trend straining the traditional layering of the transport stack
associated with the SOCK_STREAM interface is the widespread interest in
ubiquitous deployment of encryption to guarantee confidentiality,
authenticity, and integrity, in the face of pervasive surveillance
<xref target="RFC7258"/>. Layering the most widely deployed encryption technology,
Transport Layer Security (TLS), strictly atop TCP (i.e., via a TLS library
such as OpenSSL that uses the sockets API) requires the encryption-layer
handshake to happen after the transport-layer handshake, which increases
connection setup latency on the order of one or two round-trip times, an
unacceptable delay for many applications. Integrating cryptographic state
setup and maintenance into the path abstraction naturally complements efforts
in new protocols (e.g. QUIC <xref target="I-D.ietf-quic-transport"/>) to
mitigate this strict layering.</t>

<t>To meet these challenges, we present the Post-Sockets Application Programming
Interface (API), described in detail in this work. Post is designed to be
language, transport protocol, and architecture independent, allowing
applications to be written to a common abstract interface, easily ported among
different platforms, and used even in environments where transport protocol
selection may be done dynamically, as proposed in the IETF’s Transport Services
working group.</t>

<t>Post replaces the traditional SOCK_STREAM abstraction with a Message
abstraction, which can be seen as a generalization of the Stream Control
Transmission Protocol’s <xref target="RFC4960"/> SOCK_SEQPACKET service. Messages are sent
and received on Carriers, which logically group Messages for transmission and
reception. For backward compatibility, bidirectional byte stream protocols are
represented as a pair of Messages, one in each direction, that can only be marked
complete when the sending peer has finished transmitting data.</t>

<t>Post replaces the notions of a socket address and connected
socket with an Association with a remote endpoint via set of Paths.
Implementation and wire format for transport protocol(s) implementing the Post
API are explicitly out of scope for this work; these abstractions need not map
directly to implementation-level concepts, and indeed with various amounts of
shimming and glue could be implemented with varying success atop any
sufficiently flexible transport protocol.</t>

<t>The key features of Post as compared with the existing sockets API are:</t>

<t><list style="symbols">
  <t>Explicit Message orientation, with framing and atomicity guarantees for
Message transmission.</t>
  <t>Asynchronous reception, allowing all receiver-side interactions to be
event-driven.</t>
  <t>Explicit support for multistreaming and multipath transport protocols and
network architectures.</t>
  <t>Long-lived Associations, whose lifetimes may not be bound to underlying
transport connections. This allows associations to cache state and
cryptographic key material to enable fast resumption of communication, and for
the implementation of the API to explicitly take care of connection establishment
mechanics such as connection racing <xref target="RFC6555"/> and peer-to-peer rendezvous
<xref target="RFC5245"/>.</t>
  <t>Transport protocol stack independence, allowing applications to be written
in terms of the semantics best for the application’s own design, separate
from the protocol(s) used on the wire to achieve them. This enables
applications written to a single API to make use of transport protocols in
terms of the features they provide, as in <xref target="I-D.ietf-taps-transports"/>.</t>
</list></t>

<t>This work is the synthesis of many years of Internet transport protocol
research and development. It is inspired by concepts from the Stream Control
Transmission Protocol (SCTP) <xref target="RFC4960"/>, TCP Minion <xref target="I-D.iyengar-minion-protocol"/>,
and MinimaLT <xref target="MinimaLT"/>, among other transport protocol
modernization efforts. We present Post as an illustration of what is
possible with present developments in transport protocols when freed from the
strictures of the current sockets API. While much of the work for building
parts of the protocols needed to implement Post are already ongoing in other
IETF working groups (e.g. MPTCP, QUIC, TLS), we argue that an abstract
programming interface unifying access all these efforts is necessary to fully
exploit their potential.</t>

</section>
<section anchor="abstractions-and-terminology" title="Abstractions and Terminology">

<figure title="Abstractions and relationships in Post Sockets" anchor="fig-abstractions"><artwork><![CDATA[
           +===============+
           |    Message    |
           +===============+
                |    ^         |               |
          send()|    |ready()  |initiate()     |listen()
                V    |         V               V
           +=======================+         +============+
           |                       | accept()|            |
           |       Carrier         |<--------|  Listener  |
           |                       |         |            |
           +=======================+         +============+
            |1        |          n|                |             +=========+
            |         |           |1               |         +---|  Local  |
            | +===============+  +=======================+   |   +=========+
            | |               |  |                       |---+
            | | Configuration |--|      Association      |       +=========+
            | |               |  |                       |-------|  Remote |
            | +===============+  +=======================+       +=========+
            |         |                1| durable end-to-end
            +-------+ |                 | state via many paths,
                    | |                 | policies, and prefs  
                   n| |                n|
               +===========+       +==========+
     ephemeral |           |       |          |
   transport & | Transient |-------|   Path   | properties of
  crypto state |           |n     1|          | address pair
               +===========+       +==========+

]]></artwork></figure>

<t>Post is based on a small set of abstractions, centered around a Message Carrier
as the entry point for an application to the networking API.
The relationships among them are shown in Figure <xref target="fig-abstractions"/> and detailed in this section.</t>

<section anchor="carrier" title="Message Carrier">

<t>A Message Carrier (or simply Carrier) is a transport protocol stack-independent
interface for sending and receiving messages between an application and a remote
endpoint; it is roughly analogous to a socket in the present sockets API.</t>

<t>Sending a Message over a Carrier is driven by the application, while receipt
is driven by the arrival of the last packet that allows the Message to be
assembled, decrypted, and passed to the application. Receipt is therefore
asynchronous; given the different models for asynchronous I/O and concurrency
supported by different platforms, it may be implemented in any number of ways.
The abstract API provides only for a way for the application to register
how it wants to handle incoming messages.</t>

<t>All the Messages sent to a Carrier will be received on the
corresponding Carrier at the remote endpoint, though not necessarily
reliably or in order, depending on Message properties and the underlying
transport protocol stack.</t>

<t>A Carrier that is backed by current transport protocol stack state (such as a
TCP connection; see <xref target="transient"/>) is said to be “active”: messages can be
sent and received over it. A Carrier can also be “dormant”: there is long-term
state associated with it (via the underlying Association; see
<xref target="association"/>), and it may be able to reactivated, but messages cannot be
sent and received immediately. Carriers become dormant when the underlying
transport protocol stack determines that an underlying connection has been
lost and there is insufficient state in the Association to re-establish it
(e.g., in the case of a server-side Carrier where the client’s address has
changed unexpectedly). Passive close can be handled by the application via an
event on the carrier. Attempting to use a carrier after passive close results
in an error.</t>

<t>If supported by the underlying transport protocol stack, a Carrier may be
forked: creating a new Carrier associated with a new Carrier at the same remote
endpoint. The semantics of the usage of multiple Carriers based on the same
Association are application-specific. When a Carrier is forked, its
corresponding Carrier at the remote endpoint receives a fork request, which it
must accept in order to fully establish the new carrier. Multiple Carriers
between endpoints are implemented differently by different transport protocol
stacks, either using multiple separate transport-layer connections, or using
multiple streams of multistreaming transport protocols.</t>

<t>To exchange messages with a given remote endpoint, an application may initiate
a Carrier given its remote (see <xref target="remote"/> and local (see <xref target="local"/>)
identities; this is an equivalent to an active open. There are four special
cases of Carriers, as well, supporting different initiation and
interaction patterns, defined in the subsections below.</t>

<t><list style="symbols">
  <t>Listener:
A Listener is a special case of Message Carrier which only responds to
requests to create a new Carrier from a remote endpoint, analogous to a server
or listening socket in the present sockets API. Instead of being bound to a
specific remote endpoint, it is bound only to a local identity; however, its
interface for accepting fork requests is identical to that for fully fledged
Carriers.</t>
  <t>Source:
A Source is a special case of Message Carrier over which messages can only be
sent, intended for unidirectional applications such as multicast transmitters.
Sources cannot be forked, and need not accept forks.</t>
  <t>Sink:
A Sink is a special case of Message Carrier over which messages can only
be received, intended for unidirectional applications such as multicast
receivers. Sinks cannot be forked, and need not accept forks.</t>
  <t>Responder:
A Responder is a special case of Message Carrier which may receive messages
from many remote sources, for cases in which an application will only ever
send Messages in reply back to the source from which a Message was received.
This is a common implementation pattern for servers in client-server
applications. A Responder’s receiver gets a Message, as well as a Source to
send replies to. Responders cannot be forked, and need not accept forks.</t>
</list></t>

</section>
<section anchor="message" title="Message">

<t>A Message is the unit of communication between applications. Messages
can represent relatively small structures, such as requests in a
request/response protocol such as HTTP; relatively large
structures, such as files of arbitrary size in a filesystem; and structures of
indeterminate length, such as a stream of bytes in a protocol like TCP.</t>

<t>In the general case, there is no mapping between a Message and packets sent by
the underlying protocol stack on the wire: the transport protocol may freely
segment messages and/or combine messages into packets. However, a message may be
marked as immediate, which will cause it to be sent in a single packet when
possible.</t>

<t>Content may be sent and received either as Complete or Partial Messages.
Dealing with Complete Messages should be preferred for simplicity whenever
possible based on the underlying protocol. It is always possible to send Complete
Messages, but only protocols that have a fixed maximum message length may
allow clients to receive Messages using an API that guarantees Complete Messages.
Sending and receiving Partial Messages (that is, a Message whose content spans multiple
calls or callbacks) is always possible.</t>

<t>To send a Message, either Complete or Partial, the Message content is passed into the
Carrier, and client provides a set of callbacks to know when the Message was delivered or
acknowledged. The client of the API may use the callbacks to pace the sending of
Messages.</t>

<t>To receive a Message, the client of the API schedules a completion to be called when
a Complete or Partial Message is available. If the client is willing to accept Partial Messages,
it can specify the minimum incomplete Message length it is willing to receive at once,
and the maximum number of bytes it is willing to receive at once. If the client wants
Complete Messages, there are no values to tune. The scheduling of the receive completion
indicates to the Carrier that there is a desire to receive bytes, effectively creating a “pull
model” in which backpressure may be applied if the client is not receiving Messages
or Partial Messages quickly enough to match the peer’s sending rate. The Carrier may
have some minimal buffer of incoming Messages ready for the client to read to reduce
latency.</t>

<t>When receiving a Complete Message, the entire content of the Message must
be delivered at once, and the Message is not delivered at all if the full Message
is not received.  This implies that both the sending and receiving endpoint,
whether in the application or the carrier, must guarantee storage for the full
size of a Message.</t>

<t>Partial Messages may be sent or received in several stages, with a handle
representing the total Message being associated with each portion of the
content. Each call to send or receive also indicates whether or not the Message
is now complete. This approach is necessary whenever the size of the
Message does not have a known bound, or the size is too large to process
and hold in memory. Protocols that only present a concept
of byte streams represent their data as single Messages with unknown bounds.
In the case of TCP, the client will receive a single Message in pieces using the
Partial Message API, and that Message will only be marked as complete when
the peer has sent a FIN.</t>

<t>Messages are sent over and received from Message Carriers (see <xref target="carrier"/>).</t>

<t>On sending, Messages have properties that allow the application to specify its
requirements with respect to reliability, ordering, priority, idempotence, and
immediacy; these are described in detail below. Messages may also have arbitrary
properties which provide additional information to the underlying transport
protocol stack on how they should be handled, in a protocol-specific way. These
stacks may also deliver or set properties on received messages, but in the
general case a received messages contains only a sequence of ordered bytes.
Message properties include:</t>

<t><list style="symbols">
  <t>Lifetime and Partial Reliability:
A Message may have a “lifetime” – a wall clock duration before which the
Message must be available to the application layer at the remote end. If a
lifetime cannot be met, the Message is discarded as soon as possible. Messages
without lifetimes are sent reliably if supported by the transport protocol
stack. Lifetimes are also used to prioritize Message delivery.  <vspace blankLines='1'/>
There is no guarantee that a Message will not be delivered after the end of
its lifetime; for example, a Message delivered over a strictly reliable
transport will be delivered regardless of its lifetime. Depending on the
transport protocol stack used to transmit the message, these lifetimes may
also be signalled to path elements by the underlying transport, so that path
elements that realize a lifetime cannot be met can discard frames containing
the Messages instead of forwarding them.</t>
  <t>Priority:
Messages have a “niceness” – a priority among other messages sent over the
same Carrier in an unbounded hierarchy most naturally represented as a
non-negative integer. By default, Messages are in niceness class 0, or highest
priority. Niceness class 1 Messages will yield to niceness class 0 Messages
sent over the same Carrier, class 2 to class 1, and so on. Niceness may be
translated to a priority signal for exposure to path elements (e.g. DSCP
code point) to allow prioritization along the path as well as at the sender and
receiver. This inversion of normal schemes for expressing priority has a
convenient property: priority increases as both niceness and lifetime
decrease. A Message may have both a niceness and a lifetime – Messages with
higher niceness classes will yield to lower classes if resource constraints
mean only one can meet the lifetime.</t>
  <t>Dependence:
A Message may have “antecedents” – other Messages on which it
depends, which must be delivered before it (the “successor”) is delivered.
The sending transport uses deadlines, niceness, and antecedents, along with
information about the properties of the Paths available, to determine when to
send which Message down which Path.</t>
  <t>Idempotence:
A sending application may mark a Message as “idempotent” to signal to the
underlying transport protocol stack that its application semantics make it
safe to send in situations that may cause it to be received more than once
(i.e., for 0-RTT session resumption as in TCP Fast Open, TLS 1.3, and QUIC).</t>
  <t>Immediacy:
A sending application may mark a Message as “immediate” to signal to the
underlying transport protocol stack that its application semantics require it to
be placed in a single packet, on its own, instead of waiting to be combined with
other messages or parts thereof (i.e., for media transports and interactive
sessions with small messages).</t>
</list></t>

<t>Senders may also be asynchronously notified of three events on Messages they
have sent: that the Message has been transmitted, that the Message has been
acknowledged by the receiver, or that the Message has expired before
transmission/acknowledgement. Not all transport protocol stacks will support
all of these events.</t>

</section>
<section anchor="association" title="Association">

<t>An Association contains the long-term state necessary to support
communications between a Local (see <xref target="local"/>) and a Remote (see <xref target="remote"/>)
endpoint, such as trust model information, including pinned public
keys or anchor certificates, cryptographic session resumption parameters,
or rendezvous information. It uses information from the Configuration
(see <xref target="Configuration"/>) to constrain the selection of
transport protocols and local interfaces to create Transients (see
<xref target="transient"/>) to carry Messages; and information about the paths through the
network available available between them (see <xref target="path"/>).</t>

<t>All Carriers are bound to an Association. New Carriers will
reuse an Association if they can be carried from the same Local to the same
Remote over the same Paths; this re-use of an Association may implies the
creation of a new Transient.</t>

<t>Associations may exist and be created without a Carrier. This may be done if
peer cryptographic state such as a pre-shared key is established out-of-band.
Thus, Associations may be created without the need to send application data
to a peer, that is, without a Carrier. Associations are mutable. Association
state may expire over time, after which it is removed from the Association,
and Transients may export cryptographic state to store in an Association as needed.
Moreover, this state may be exported directly into the Association or modified
before insertion. This may be needed to diversify ephemeral Transient keying
material from the longer-term Association keying material.</t>

<t>A primary use of Association state is to allow new Associations and their derived
Carriers to be quickly created without performing in-band cryptographic handshakes.
See <xref target="I-D.kuehlewind-taps-crypto-sep"/> for more details about this separation.</t>

</section>
<section anchor="remote" title="Remote">

<t>A Remote represents information required to establish and maintain a
connection with the far end of an Association: name(s), address(es), and
transport protocol parameters that can be used to establish a Transient;
transport protocols to use; trust model information, inherited from the
relevant Association, used to identify the remote on connection establishment;
and so on. Each Association is associated with a single Remote, either explicitly by
the application (when created by the initiation of a Carrier) or a
Listener (when created by forking a Carrier on passive open).</t>

<t>A Remote may be resolved, which results in zero or more Remotes with more
specific information. For example, an application may want to establish a
connection to a website identified by a URL https://www.example.com. This URL
would be wrapped in a Remote and passed to a call to initiate a 
Carrier. The first pass resolution might parse the URL, decomposing it into a
name, a transport port, and a transport protocol to try connecting with. A
second pass resolution would then look up network-layer addresses associated
with that name through DNS, and store any certificates available from DANE.
Once a Remote has been resolved to the point that a transport protocol stack
can use it to create a Transient, it is considered fully resolved.</t>

</section>
<section anchor="local" title="Local">

<t>A Local represents all the information about the local endpoint necessary to
establish an Association or a Listener. It encapsulates the Provisioning Domain
(PvD) of a single interface in the multiple provisioning domain architecture
<xref target="RFC7556"/>, and adds information about the service endpoint (transport protocol
port), and, per <xref target="I-D.pauly-taps-transport-security"/>, cryptographic identities
(certificates and associated private keys) bound to this endpoint.</t>

</section>
<section anchor="Configuration" title="Configuration">

<t>A Configuration encapsulates an application’s preferences around Path
selection and protocol options.</t>

<t>Each Association has exactly one Configuration, and all Carriers belonging
to that Association share the same Configuration.</t>

<t>The application cannot modify the Configuration for a Carrier or Association
once it is set. If a new set of options needs to be used, then the application needs
a new Carrier or Association instance. This is necessary to ensure that a
single Carrier can consistently track the Paths and protocol options it uses,
since it is usually not possible to modify these properties without breaking connectivity.</t>

<t>To influence Path selection, the application can configure a set of requirements,
preferences, and restrictions concerning which Paths may be selected by the
Association to use for creating Transients between a Local and a Remote. For example,
a Configuration can specify that the application prefers Wi-Fi access over
LTE when roaming on a foreign LTE network, due to monetary cost to the user.</t>

<t>The Association uses the Configuration’s Path preferences as a key part of determining
the Paths to use for its Transients. The Configuration is provided as input when examining
the complete list of available Paths on the system (to limit the list, or order the Paths by
preference). The system’s policy will further restrict and modify the Path that is ultimately
selected, using other aspects of the Configuration (protocol options and originating application)
to select the most appropriate Path.</t>

<t>To influence protocol selection and options, the Configuration contains one
or more allowed Protocol Stack Configurations. Each of these is comprised of
application- and transport-layer protocols that may be used together to communicate
to the Remote, along with any protocol-specific options. For example, a
Configuration could specify two alternate, but equivalent, protocol stacks:
one using HTTP/2 over TLS over TCP, and the other using QUIC over UDP.
Alternatively, the Configuration could specify two protocol stacks with the same
protocols, but different protocol options: one using TLS with TLS 1.3 0-RTT enabled
and TCP with TCP Fast-Open enabled, and one using TLS with out 0-RTT and TCP
without TCP Fast-Open.</t>

<t>Protocol-specific options within the Configuration include trust settings and acceptable
cryptographic algorithms to be used by security protocols. These may be configured for
specific protocols to allow different settings for each (such as between TLS over TCP and
TLS for use with QUIC), or set as default security settings on the Configuration to
be used by any protocol that needs to evaluate trust. Trust settings may
include certificate anchors and certificate pinning options.</t>

</section>
<section anchor="transient" title="Transient">

<t>A Transient represents a binding between a Carrier and the instance of the
transport protocol stack that implements it. As an Association contains
long-term state for communications between two endpoints, a Transient contains
ephemeral state for a single transport protocol over a one or more Paths at a
given point in time.</t>

<t>A Carrier may be served by multiple Transients at once, e.g. when
implementing multipath communication such that the separate paths are exposed to
the API by the underlying transport protocol stack. Each Transient serves only
one Carrier, although multiple Transients may share the same underlying
protocol stack; e.g. when multiplexing Carriers over streams in a multistreaming
protocol.</t>

<t>Transients are generally not exposed by the API to the application, though
they may be accessible for debugging and logging purposes.</t>

</section>
<section anchor="path" title="Path">

<t>A Path represents information about a single path through the network used by an
Association, in terms of source and destination network and transport layer
addresses within an addressing context, and the provisioning domain <xref target="RFC7556"/>
of the local interface. This information may be learned through a resolution,
discovery, or rendezvous process (e.g. DNS, ICE), by measurements taken by the
transport protocol stack, or by some other path information discovery mechanism.
It is used by the transport protocol stack to maintain and/or (re-)establish
communications for the Association.</t>

<t>The set of available properties is a function of the transport protocol stacks
in use by an association. However, the following core properties are generally
useful for applications and transport layer protocols to choose among paths
for specific Messages:</t>

<t><list style="symbols">
  <t>Maximum Transmission Unit (MTU): the maximum size of an Message’s payload
(subtracting transport, network, and link layer overhead) which will likely
fit into a single frame. Derived from signals sent by path elements, where
available, and/or path MTU discovery processes run by the transport layer.</t>
  <t>Latency Expectation: expected one-way delay along the Path. Generally
provided by inline measurements performed by the transport layer, as opposed
to signaled by path elements.</t>
  <t>Loss Probability Expectation: expected probability of a loss of any
given single frame along the Path. Generally provided by inline measurements
performed by the transport layer, as opposed to signaled by path elements.</t>
  <t>Available Data Rate Expectation: expected maximum data rate along the
Path. May be derived from passive measurements by the transport layer, or from
signals from path elements.</t>
  <t>Reserved Data Rate: Committed, reserved data rate for the given
Association along the Path. Requires a bandwidth reservation service in the
underlying transport protocol stack.</t>
  <t>Path Element Membership: Identifiers for some or all nodes along the
path, depending on the capabilities of the underlying network layer protocol
to provide this.</t>
</list></t>

<t>Path properties are generally read-only. MTU is a property of the underlying
link-layer technology on each link in the path; latency, loss, and rate
expectations are dynamic properties of the network configuration and network
traffic conditions; path element membership is a function of network topology.
In an explicitly multipath architecture, application and transport layer
requirements can be met by having multiple paths with different properties to
select from. Transport protocol stacks can also provide signaling to devices
along the path, but this signaling is derived from information provided to the
Message abstraction.</t>

</section>
</section>
<section anchor="abstract-programming-interface" title="Abstract Programming Interface">

<t>We now turn to the design of an abstract programming interface to provide a
simple interface to Post’s abstractions, constrained by the following design
principles:</t>

<t><list style="symbols">
  <t>Flexibility is paramount. So is simplicity. Applications must be
given as many controls and as much information as they may need, but they must
be able to ignore controls and information irrelevant to their operation. This
implies that the “default” interface must be no more complicated than BSD
sockets, and must do something reasonable.</t>
  <t>Reception is an inherently asynchronous activity. While the API is
designed to be as platform-independent as possible, one key insight it is
based on is that an Message receiver’s behavior in a packet-switched network is
inherently asynchronous, driven by the receipt of packets, and that this
asynchronicity must be reflected in the API. The actual implementation of
receive and event handling will need to be aligned to the method a given
platform provides for asynchronous I/O.</t>
  <t>A new API cannot be bound to a single transport protocol and expect
wide deployment. As the API is transport-independent and may support runtime
transport selection, it must impose the minimum possible set of constraints on
its underlying transports, though some API features may require underlying
transport features to work optimally. It must be possible to implement Post
over vanilla TCP in the present Internet architecture.</t>
</list></t>

<t>The API we design from these principles is centered around a Carrier, which
can be created actively via initiate() or passively via a listen(); the latter
creates a Listener from which new Carriers can be accept()ed.  Messages may be
created explicitly and passed to this Carrier, or implicitly through a
simplified interface which uses default message properties (reliable transport
without priority or deadline, which guarantees ordered delivery over a single
Carrier when the underlying transport protocol stack supports it).</t>

<t>For each connection between a Local and a Remote a new Carrier is created and 
destroyed when the connection is closed. However, a new Carrier may use an existing
Association if present for the requested Local-Remote pair and permitted by the
PolicyContext that can be provided at Carrier initiation. Further the system-wide
PolicyContext can contain more information that determine when to create or destroy
Associations other than at Carrier initiation. E.g. an Association can be created 
at system start, based on the configured PolicyContext or also by a manual action of 
an single application, for Local-Remote pairs that are known to be likely used soon, and 
to pre-establish, e.g., cryptographic context as well as potentially collect current information
about path capabilities. Every time an actual connection with a specific PSI is established between the 
Local and Remote, the Association learns new Path information and stores them. This
information can be used when a new transient is created, e.g. to decide which PSI
to use (to provide the highest probably for a successful connection attempt) or which
PSIs to probe for (first). A Transient is created when an application actually sends a 
Message over a Carrier. As further explained below this step can actually create multiple 
transients for probing or assign a new transient to an already active PSI, e.g. if multi-streaming
is provided and supported for these kind of use on both sides.</t>

<section anchor="example-connection-patterns" title="Example Connection Patterns">

<t>Here, we illustrate the usage of the API for common connection patterns. Note
that error handling is ignored in these illustrations for ease of reading.</t>

<section anchor="client-server" title="Client-Server">

<t>Here’s an example client-server application. The server echoes messages. The
client sends a message and prints what it receives.</t>

<t>The client in <xref target="fig-client"/> connects, sends a message, and sets up a receiver
to print messages received in response. The carrier is inactive after the
Initiate() call; the Send() call blocks until the carrier can be activated.</t>

<figure title="Example client" anchor="fig-client"><artwork><![CDATA[
// connect to a server given a remote
func sayHello() {

    carrier := Initiate(local, remote)

    carrier.Send([]byte("Hello!"))
    carrier.Ready(func (msg InMessage) {
        fmt.Println(string([]byte(msg))
        return false
    })
    carrier.Close()
}
]]></artwork></figure>

<t>The server in <xref target="fig-server"/> creates a Listener, which accepts Carriers and passes them to a server. The server echos the content of each message it receives.</t>

<figure title="Example server" anchor="fig-server"><artwork><![CDATA[
// run a server for a specific carrier, echo all its messages
func runMyServerOn(carrier Carrier) {
    carrier.Ready(func (msg InMessage) {
        carrier.Send(msg)
    })
}

// accept connections forever, spawn servers for them
func acceptConnections() {
    listener := Listen(local)
    listener.Accept(func(carrier Carrier) bool {
        go runMyServerOn(carrier)
        return true
    })
}
]]></artwork></figure>

<t>The Responder allows the server to be significantly simplified, as shown in <xref target="fig-responder"/>.</t>

<figure title="Example responder" anchor="fig-responder"><artwork><![CDATA[
func echo(msg InMessage, reply Sink) {
    reply.Send(msg)
}

Respond(local, echo)
]]></artwork></figure>

</section>
<section anchor="client-server-with-happy-eyeballs-and-0-rtt-establishment" title="Client-Server with Happy Eyeballs and 0-RTT establishment">

<t>The fundamental design of a client need not change at all for happy eyeballs
<xref target="RFC6555"/> (selection of multiple potential protocol stacks through connection
racing); this is handled by the Post Sockets implementation automatically. If
this connection racing is to use 0-RTT data (i.e., as provided by TCP Fast Open
<xref target="RFC7413"/>, the client must mark the outgoing message as idempotent.</t>

<figure><artwork><![CDATA[
// connect to a server given a remote and send some 0-RTT data
func sayHelloQuickly() {

    carrier := Initiate(local, remote)

    carrier.SendMsg(OutMessage{Content: []byte("Hello!"), Idempotent: true}, nil, nil, nil)
    carrier.Ready(func (msg InMessage) {
        fmt.Println(string([]byte(msg)))
        return false
    })
    carrier.Close()
}
]]></artwork></figure>

</section>
<section anchor="peer-to-peer-with-network-address-translation" title="Peer to Peer with Network Address Translation">

<t>In the client-server examples shown above, the Remote given to the Initiate call
refers to the name and port of the server to connect to. This need not be the
case, however; a Remote may also refer to an identity and a rendezvous point for
rendezvous as in ICE <xref target="RFC5245"/>. Here, each peer does its own Initiate call
simultaneously, and the result on each side is a Carrier attached to an
appropriate Association.</t>

</section>
<section anchor="multicast-receiver" title="Multicast Receiver">

<t>A multicast receiver is implemented using a Sink attached to a Local
encapsulating a multicast address on which to receive multicast datagrams. The
following example prints messages received on the multicast address forever.</t>

<figure><artwork><![CDATA[
func receiveMulticast() {
    sink = NewSink(local)
    sink.Ready(func (msg InMessage) {
        fmt.Println(string([]byte(msg)))
        return true
    })
}
]]></artwork></figure>

</section>
<section anchor="association-bootstrapping" title="Association Bootstrapping">

<t>Here, we show how Association state may be initialized without a carrier.
The goal is to create a long-term Association from which Carriers may be derived
and, if possible, used immediately. Per <xref target="I-D.pauly-taps-transport-security"/>,
a first step is to specify trust model constraints, such as pinned public keys
and anchor certificates, which are needed to create Remote connections.</t>

<t>We begin by creating shared security parameters that will be used later for creating
a remote connection.</t>

<figure><artwork><![CDATA[
// create security parameters with a set of trusted certificates
func createParameters(trustedCerts []Certificate) Parameters {
    parameters := Parameters()
    parameters = parameters.SetTrustedCerts(trustedCerts)
    return parameters
}
]]></artwork></figure>

<t>Using these statically configured parameters, we now show how to create an Association
between a Local and Remote using these parameters.</t>

<figure><artwork><![CDATA[
// create an Association using shared parameters
func createAssociation(local Local, remote Remote, parameters Parameters) Association {
    association := NewAssociation(local, remote, parameters)
    return association
}
]]></artwork></figure>

<t>We may also create an Association with a pre-shared key configured out-of-band.</t>

<figure><artwork><![CDATA[
// create an Association using a pre-shared key
func createAssociationWithPSK(local Local, remote Remote, parameters Parameters, preSharedKey []byte) Association {
    association := NewAssociation(local, remote, parameters)
    association = association.SetPreSharedKey(preSharedKey)
    return association
}
]]></artwork></figure>

<t>We now show how to create a Carrier from an existing, pre-configured Association.
This Association may or may not contain shared cryptographic static between the
Local and Remote, depending on how it was configured.</t>

<figure><artwork><![CDATA[
// open a connection to a server using an existing Association and send some data,
// which will be sent early if possible.
func sayHelloWithAssociation(association Association) {
    carrier := association.Initiate()

    carrier.SendMsg(OutMessage{Content: []byte("Hello!"), Idempotent: true}, nil, nil, nil)
    carrier.Ready(func (msg InMessage) {
        fmt.Println(string([]byte(msg)))
        return false
    })
    carrier.Close()
}
]]></artwork></figure>

</section>
</section>
<section anchor="sec-dynamics" title="API Dynamics">

<t>As Carriers provide the central entry point to Post, they are key to API
dynamics. The lifecycle of a carrier is shown in <xref target="fig-carrier-lc"/>. Carriers
are created by active openers by calling Initiate() given a Local and a Remote,
and by passive openers by calling Listen() given a Local; the .Accept() method
on the listener Carrier can then be used to create active carriers. By default,
the underlying Association is automatically created and managed by the
underlying API. This underlying Association can be accessed by the Carrier’s
.Association() method. Alternately, an association can be explicitly created
using NewAssociation(), and a Carrier on the association may be accessed or
initiated by calling the association’s .Initiate() method.</t>

<t>Once a Carrier has been created (via Initiate(), Association.Initiate(),
NewSource(), NewSink(), or Listen()/Accept()), it may be used to send and
receive Messages. The existence of a Carrier does not imply the existence of
an active Transient or associated transport-layer connection; these may be
created when the carrier is, or may be deferred, depending on the network
environment, configuration, and protocol stacks available.</t>

<figure title="Carrier and Association Life Cycle" anchor="fig-carrier-lc"><artwork><![CDATA[
 Listen(local)   Initiate(local,remote)   NewSource(local,remote)
      |                     |             or NewSink(local)
  [ Carrier  ]              |                    |
  [(listener)]              +--------------------+
      |                     V                    
  .Accept()-----------> [Carrier] -+----------> .Close()
                         |     ^   |  close    [ Carrier  ]
                         |     |   +- event -> [ (closed) ]
                         |     |          
              .Association()  .Carriers()
                         |    .Initiate()
                         V     |
                     [Association]   
                           ^
                           |
              NewAssociation(local,remote)
]]></artwork></figure>

<t>Access to more detailed information is possible through accessors on Carriers
and Associations, as shown in <xref target="fig-accessors"/>. The set of currently active
Transients can be accessed through the Carrier’s .Transients() methods. The
active path(s) used by a Transient can be accessed through the Transient’s
.Paths() method, and the set of all paths for which properties are cached by
an Association can be accessed through the Association’s .Paths() method. The
set of active carriers on an association can be accessed through the
Association’s .Carriers() method. Access to transients and paths is not
necessary in normal operation; these accessors are provided primarily for
logging and debugging purposes.</t>

<figure title="Accessors on Carriers and Associations" anchor="fig-accessors"><artwork><![CDATA[
          [Carrier]---.Transients()--->[Transient]
           |     ^                       |
           |     |                       |
.Association()  .Carriers()           .Paths()
           |    .Initiate()              |
           V     |                       V
        [Association]---.Paths()------>[Path]       
]]></artwork></figure>

<t>Each Carrier has a .Send() method, by which Messages can be sent with given
properties, and a .Ready() method, which supplies a callback for reading
Messages from the remote side. .Send() is not available on Sinks, and .Ready()
is not available on Sources. Carriers also provide .OnSent(), .OnAcked(), and
.OnExpired() calls for binding default send event handlers to the Carrier, and
.OnClosed() for handling passive close notifications.</t>

<figure title="Sending and Receiving Messages and Events" anchor="fig-message"><artwork><![CDATA[
                                  +---------[incoming]-----------+
                                  |         [Message ]           V
[outgoing] ---> .Send() --->  [Carrier] <---- .Ready() <---- [Receiver]
[Message ]                        |
                                  +--- .OnSent()
                                  +--- .OnAcked()
                                  +--- .OnExpired()
                                  +--- .OnClosed()       
]]></artwork></figure>

<t>An application may have a global Configuation, as well as more specific
Configurations to apply to the establishment of a given Association or Carrier.
These Configurations are optional arguments to the Association and Carrier
creation calls.</t>

<t>In order to initiate a connection with a remote endpoint, a user of Post Sockets
must start from a Remote (see <xref target="remote"/>). A Remote encapsulates identifying
information about a remote endpoint at a specific level of resolution. A new
Remote can be wrapped around some identifying information by via the NewRemote()
call. A Remote has a .Resolve() method, which can be iteratively revoked to
increase the level of resolution; a call to Resolve on a given Remote may result
in one to many Remotes, as shown in <xref target="fig-remote"/>.  Remotes at any level of
resolution may be passed to Post Sockets calls; each call will continue
resolution to the point necessary to establish or resume a Carrier.</t>

<figure title="Recursive resolution of Remotes" anchor="fig-remote"><artwork><![CDATA[
                          +----------------------------+
                        n |                            | 1
NewRemote(identifiers) ---+--->[Remote] --.Resolve()---+
]]></artwork></figure>

<t>Information about the local endpoint is also necessary to establish an
Association, whether explicitly or implicitly through the creation of a
Carrier or Listener. This is passed in the form of a Local (see <xref target="local"/>). A
Local is created with a NewLocal() call, which takes a Configuration
(including certificates to present and secret keys associated with them) and
identifying information (interface(s) and port(s) to use).</t>

</section>
</section>
<section anchor="implementation-considerations" title="Implementation Considerations">

<t>Here we discuss an incomplete list of API implementation considerations that
have arisen with experimentation with prototype implementations of Post.</t>

<section anchor="sec-psi" title="Protocol Stack Instance (PSI)">

<t>A PSI encapsulates an arbitrary stack of protocols (e.g., TCP over IPv6,
SCTP over DTLS over UDP over IPv4).  PSIs provide the bridge between the
interface (Carrier) plus the current state (Transients) and the implementation
of a given set of transport services <xref target="I-D.ietf-taps-transports"/>.</t>

<t>A given implementation makes one or more possible protocol stacks available
to its applications. Selection and configuration among multiple PSIs is
based on system-level or application policies, as well as on network
conditions in the provisioning domain in which a connection is made.</t>

<figure title="Example Protocol Stack Instances" anchor="fig-psi"><artwork><![CDATA[
+=========+    +=========+   +==========+      +==========+
| Carrier |    | Carrier |   | Carrier  |      | Carrier  |
+=========+    +=========+   +==========+      +==========+
     |               |              |                 |
+=========+    +=========+   +==========+      +==========+
|Transient|    |Transient|   |Transient |      |Transient |
+=========+    +=========+   +==========+      +==========+
     |                  \     /                 /        \
+=========+           +=========+      +=========+      +=========+
|   PSI   |           |   PSI   |      |   PSI   |      |   PSI   |
+===+-----++          +===+-----++     +===+-----++    ++-----+===+
    |TLS   |              |SCTP  |         |TLS   |    |   TLS|
    |TCP   |              |DTLS  |         |TCP   |    |   TCP|
    |IPv6  |              |UDP   |         |IPv6  |    |  IPv4|
    |802.3 |              |IPv6  |         |802.11|    |802.11|
    +------+              |802.3 |         +------+    +------+
                          +------+
(a) Transient  (b) Carrier multiplexing   (c) Multiple candidates
 bound to PSI   over a multi-streaming     racing during session
                transport protocol         establishment
]]></artwork></figure>

<t>For example, <xref target="fig-psi"/>(a) shows a TLS over TCP stack, usable on most
network connections. Protocols are layered to ensure that the PSI provides
all the transport services required by the application.
A single PSI may be bound to multiple Carriers, as shown in
<xref target="fig-psi"/>(b): a multi-streaming transport protocol like QUIC or SCTP can
support one carrier per stream. Where multi-streaming transport is not
available, these carriers could be serviced by different PSIs on different
flows. On the other hand, multiple PSIs are bound to a single transient
during establishment, as shown in <xref target="fig-psi"/>(c). Here, the losing
PSI in a happy-eyeballs race will be terminated, and the carrier will
continue using the winning PSI.</t>

</section>
<section anchor="message-framing-parsing-and-serialization" title="Message Framing, Parsing, and Serialization">

<t>While some transports expose a byte stream abstraction, most higher level
protocols impose some structure onto that byte stream. That is, the higher
level protocol operates in terms of messages, protocol data units (PDUs),
rather than using unstructured sequences of bytes, with each message being
processed in turn.
Protocols are specified in terms of state machines acting on semantic
messages, with parsing the byte stream into messages being a necessary
annoyance, rather than a semantic concern.
Accordingly, Post Sockets exposes a message-based API to applications as
the primary abstraction. Protocols that deal only in byte streams, such as TCP,
represent their data in each direction as a single, long message. When framing
protocols are placed on top of byte streams, the messages used in the API
represent the framed messages within the stream.</t>

<t>There are other benefits of providing a message-oriented API beyond framing
PDUs that Post Sockets should provide when supported by the underlying
transport. These include:</t>

<t><list style="symbols">
  <t>the ability to associate deadlines with messages, for transports that
care about timing;</t>
  <t>the ability to provide control of reliability, choosing what messages to
retransmit in the event of packet loss, and how best to make use of the
data that arrived;</t>
  <t>the ability to manage dependencies between messages, when some messages
may not be delivered due to either packet loss or missing a deadline, in
particular the ability to avoid (re-)sending data that relies on a previous
transmission that was never received.</t>
</list></t>

<t>All require explicit message boundaries, and application-level framing of
messages, to be effective. Once a message is passed to Post Sockets, it can
not be cancelled or paused, but prioritization as well as lifetime and
retransmission management will provide the protocol stack with all needed
information to send the messages as quickly as possible without blocking
transmission unnecessarily.  Post Sockets provides this by handling
message, with known identity (sequence numbers, in the simple case),
lifetimes, niceness, and antecedents.</t>

<t>Transport protocols such as SCTP provide a message-oriented API that has
similar features to those we describe. Other transports, such as TCP, do
not. To support a message oriented API, while still being compatible with
stream-based transport protocols, Post Sockets must provide APIs for
parsing and serialising messages that understand the protocol data.  That
is, we push message parsing and serialisation down into the Post Sockets
stack, allowing applications to send and receive strongly typed data
objects (e.g., a receive call on an HTTP Message Carrier should return
an object representing the HTTP response, with pre-parsed status code,
headers, and any message body, rather than returning a byte array that
the application has to parse itself).
This is backwards compatible with existing protocols and APIs, since
the wire format of messages does not change, but gives a Post Sockets
stack additional information to allow it to make better use of modern
transport services.</t>

<t>The Post Sockets approach is therefore to raise the semantic level of the
transport API: applications should send and receive messages in the form of
meaningful, strongly typed, protocol data. Parsing and serialising such
messages should be a re-usable function of the protocol stack instance not
the application.  This is well-suited to implementation in modern systems
languages, such as Swift, Go, Rust, or C++, but can also be implemented
with some loss of type safety in C.</t>


</section>
<section anchor="message-size-limitations" title="Message Size Limitations">

<t>Ideally, Messages can be of infinite size. However, protocol stacks and protocol
stack implementations may impose their own limits on message sizing; For
example, SCTP <xref target="RFC4960"/> and TLS <xref target="I-D.ietf-tls-tls13"/> impose record size
limitations of 64kB and 16kB, respectively. Message sizes may also be limited by
the available buffer at the receiver, since a Message must be fully assembled by
the transport layer before it can be passed on to the application layer. Since
not every transport protocol stack implements the signaling necessary to
negotiate or expose message size limitations, these may need to be defined out
of band, and are probably best exposed through the Configuration.</t>

<t>A truly infinite message service – e.g. large file transfer where both
endpoints have committed persistent storage to the message – is probably best
realized as a layer above Post Sockets, and may be added as a new type of
Message Carrier to a future revision of this document.</t>

</section>
<section anchor="back-pressure" title="Back-pressure">

<t>Regardless of how asynchronous reception is implemented, it is important for an
application to be able to apply receiver back-pressure, to allow the protocol
stack to perform receiver flow control. Depending on how asynchronous I/O works
in the platform, this could be implemented by having a maximum number of
concurrent receive callbacks, or by bounding the maximum number of outstanding,
unread bytes at any given time, for example.</t>

</section>
<section anchor="associations-transients-racing-and-rendezvous" title="Associations, Transients, Racing, and Rendezvous">

<t>As the network has evolved, even the simple act of establishing a
connection has become increasingly complex.  Clients now regularly race
multiple connections, for example over IPv4 and IPv6, to determine which
protocol to use.  The choice of outgoing interface has also become more
important, with differential reachability and performance from multiple
interfaces. Name resolution can also give different outcomes depending on
the interface the query was issued from. Finally, but often most
significantly, NAT traversal, relay discovery, and path state maintenance
messages are an essential part of connection establishment, especially for
peer-to-peer applications.</t>

<t>Post Sockets accordingly breaks communication establishment down into
multiple phases:</t>

<t><list style="symbols">
  <t>Gathering Locals  <vspace blankLines='1'/>
The set of possible Locals is gathered.
In the simple case, this merely enumerates the local interfaces and
protocols, and allocates ephemeral source ports for transients. For
example, a system that has WiFi and Ethernet and supports IPv4 and IPv6
might gather four candidate locals (IPv4 on Ethernet, IPv6 on Ethernet,
IPv4 on WiFi, and IPv6 on WiFi) that can form the source for a transient.  <vspace blankLines='1'/>
If NAT traversal is required, the process of gathering locals becomes
broadly equivalent to the ICE candidate gathering phase <xref target="RFC5245"/>.
The endpoint determines its server reflexive locals (i.e., the
translated address of a local, on the other side of a NAT) and relayed
locals (e.g., via a TURN server or other relay), for each interface and
network protocol. These are added to the set of candidate locals for
this association.  <vspace blankLines='1'/>
Gathering locals is primarily an endpoint local operation, although it
might involve exchanges with a STUN server to derive server reflexive
locals, or with a TURN server or other relay to derive relayed locals.
It does not involve communication with the remote.</t>
  <t>Resolving the Remote  <vspace blankLines='1'/>
The remote is typically a name that
needs to be resolved into a set of possible addresses that can be used
for communication. Resolving the remote is the process of recursively
performing such name lookups, until fully resolved, to return the set
of candidates for the remote of this association.  <vspace blankLines='1'/>
How this is done will depend on the type of the Remote, and can also
be specific to each local.
A common case is when the Remote is a DNS name, in which case it is
resolved to give a set of IPv4 and IPv6 addresses representing that
name.
Some types of remote might require more complex resolution. Resolving
the remote for a peer-to-peer connection might involve communication
with a rendezvous server, which in turn contacts the peer to gain
consent to communicate and retrieve its set of candidate locals, which
are returned and form the candidate remote addresses for contacting
that peer.  <vspace blankLines='1'/>
Resolving the remote is <spanx style="emph">not</spanx> a local operation. It will involve
a directory service, and can require communication with the remote to
rendezvous and exchange peer addresses.
This can expose some or all of the candidate locals to the remote.</t>
  <t>Establishing Transients  <vspace blankLines='1'/>
The set of candidate locals and the set of candidate remotes are
paired, to derive a priority ordered set of Candidate Paths that
can potentially be used to establish a connection.  <vspace blankLines='1'/>
Then, communication is attempted over each candidate path, in
priority order. If there are multiple candidates with the same
priority, then transient establishment proceeds simultaneously
and uses the transient that wins the race to be established.
Otherwise, transients establishment is sequential, paced at a
rate that should not congest the network.
Depending on the chosen transport, this phase might involve racing
TCP connections to a server over IPv4 and IPv6 <xref target="RFC6555"/>, or
it could involve a STUN exchange to establish peer-to-peer UDP
connectivity <xref target="RFC5245"/>, or some other means.</t>
  <t>Confirming and Maintaining Transients  <vspace blankLines='1'/>
Once connectivity has been established, unused resources can be
released and the chosen path can be confirmed.
This is primarily required when establishing peer-to-peer connectivity,
where connections supporting relayed locals that were not required can
be closed, and where an associated signalling operation might be needed
to inform middleboxes and proxies of the chosen path.
Keep-alive messages may also be sent, as appropriate, to ensure NAT and
firewall state is maintained, so the transient remains operational.</t>
</list></t>

<t>By encapsulating these four phases of communication establishment into the
PSI, Post Sockets aims to simplify application development.
It can provide reusable implementations of connection racing for TCP, to enable
happy eyeballs, that will be automatically used by all TCP clients, for example.
With appropriate callbacks to drive the rendezvous signalling as part of
resolving the remote, we believe a generic ICE implementation ought also to be
possible. This procedure can even be repeated fully or partially during a
connection to enable seamless hand-over and mobility within the network stack.</t>

</section>
</section>
<section anchor="acknowledgments" title="Acknowledgments">

<t>Many thanks to Laurent Chuat and Jason Lee at the Network Security Group at ETH
Zurich for contributions to the initial design of Post Sockets. Thanks to Joe
Hildebrand, Martin Thomson, and Michael Welzl for their feedback, as well as the
attendees of the Post Sockets workshop in February 2017 in Zurich for the
discussions, which have improved the design described herein.</t>

<t>This work is partially supported by the European Commission under Horizon 2020
grant agreement no. 688421 Measurement and Architecture for a Middleboxed
Internet (MAMI), and by the Swiss State Secretariat for Education, Research, and
Innovation under contract no. 15.0268. This support does not imply endorsement.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference anchor="I-D.ietf-taps-transports">
<front>
<title>Services provided by IETF transport protocols and congestion control mechanisms</title>

<author initials='G' surname='Fairhurst' fullname='Gorry Fairhurst'>
    <organization />
</author>

<author initials='B' surname='Trammell' fullname='Brian Trammell'>
    <organization />
</author>

<author initials='M' surname='Kuehlewind' fullname='Mirja Kuehlewind'>
    <organization />
</author>

<date month='December' day='6' year='2016' />

<abstract><t>This document describes, surveys, and classifies the protocol mechanisms provided by existing IETF protocols, as background for determining a common set of transport services.  It examines the Transmission Control Protocol (TCP), Multipath TCP, the Stream Control Transmission Protocol (SCTP), the User Datagram Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), the Internet Control Message Protocol (ICMP), the Realtime Transport Protocol (RTP), File Delivery over Unidirectional Transport/ Asynchronous Layered Coding Reliable Multicast (FLUTE/ALC), and NACK- Oriented Reliable Multicast (NORM), Transport Layer Security (TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol (HTTP), when HTTP is used as a pseudotransport.  This survey provides background for the definition of transport services within the TAPS working group.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-taps-transports-14' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-taps-transports-14.txt' />
</reference>




    </references>

    <references title='Informative References'>





<reference  anchor="RFC0793" target='https://www.rfc-editor.org/info/rfc793'>
<front>
<title>Transmission Control Protocol</title>
<author initials='J.' surname='Postel' fullname='J. Postel'><organization /></author>
<date year='1981' month='September' />
</front>
<seriesInfo name='STD' value='7'/>
<seriesInfo name='RFC' value='793'/>
<seriesInfo name='DOI' value='10.17487/RFC0793'/>
</reference>



<reference  anchor="RFC4960" target='https://www.rfc-editor.org/info/rfc4960'>
<front>
<title>Stream Control Transmission Protocol</title>
<author initials='R.' surname='Stewart' fullname='R. Stewart' role='editor'><organization /></author>
<date year='2007' month='September' />
<abstract><t>This document obsoletes RFC 2960 and RFC 3309.  It describes the Stream Control Transmission Protocol (SCTP).  SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.</t><t>SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP.  It offers the following services to its users:</t><t>--  acknowledged error-free non-duplicated transfer of user data,</t><t>--  data fragmentation to conform to discovered path MTU size,</t><t>--  sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,</t><t>--  optional bundling of multiple user messages into a single SCTP packet, and</t><t>--  network-level fault tolerance through supporting of multi-homing at either or both ends of an association.</t><t> The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4960'/>
<seriesInfo name='DOI' value='10.17487/RFC4960'/>
</reference>



<reference  anchor="RFC5245" target='https://www.rfc-editor.org/info/rfc5245'>
<front>
<title>Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'><organization /></author>
<date year='2010' month='April' />
<abstract><t>This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model.  This protocol is called Interactive Connectivity Establishment (ICE).  ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).  ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP).  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5245'/>
<seriesInfo name='DOI' value='10.17487/RFC5245'/>
</reference>



<reference  anchor="RFC6555" target='https://www.rfc-editor.org/info/rfc6555'>
<front>
<title>Happy Eyeballs: Success with Dual-Stack Hosts</title>
<author initials='D.' surname='Wing' fullname='D. Wing'><organization /></author>
<author initials='A.' surname='Yourtchenko' fullname='A. Yourtchenko'><organization /></author>
<date year='2012' month='April' />
<abstract><t>When a server's IPv4 path and protocol are working, but the server's IPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to an IPv4-only client.  This is undesirable because it causes the dual- stack client to have a worse user experience.  This document specifies requirements for algorithms that reduce this user-visible delay and provides an algorithm.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6555'/>
<seriesInfo name='DOI' value='10.17487/RFC6555'/>
</reference>



<reference  anchor="RFC6698" target='https://www.rfc-editor.org/info/rfc6698'>
<front>
<title>The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA</title>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></author>
<author initials='J.' surname='Schlyter' fullname='J. Schlyter'><organization /></author>
<date year='2012' month='August' />
<abstract><t>Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used.  This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers.  This requires matching improvements in TLS client software, but no change in TLS server software.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6698'/>
<seriesInfo name='DOI' value='10.17487/RFC6698'/>
</reference>



<reference  anchor="RFC6824" target='https://www.rfc-editor.org/info/rfc6824'>
<front>
<title>TCP Extensions for Multipath Operation with Multiple Addresses</title>
<author initials='A.' surname='Ford' fullname='A. Ford'><organization /></author>
<author initials='C.' surname='Raiciu' fullname='C. Raiciu'><organization /></author>
<author initials='M.' surname='Handley' fullname='M. Handley'><organization /></author>
<author initials='O.' surname='Bonaventure' fullname='O. Bonaventure'><organization /></author>
<date year='2013' month='January' />
<abstract><t>TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers.  The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure.</t><t>Multipath TCP provides the ability to simultaneously use multiple paths between peers.  This document presents a set of extensions to traditional TCP to support multipath operation.  The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths.  This  document defines an Experimental Protocol for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='6824'/>
<seriesInfo name='DOI' value='10.17487/RFC6824'/>
</reference>



<reference  anchor="RFC7258" target='https://www.rfc-editor.org/info/rfc7258'>
<front>
<title>Pervasive Monitoring Is an Attack</title>
<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<date year='2014' month='May' />
<abstract><t>Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.</t></abstract>
</front>
<seriesInfo name='BCP' value='188'/>
<seriesInfo name='RFC' value='7258'/>
<seriesInfo name='DOI' value='10.17487/RFC7258'/>
</reference>



<reference  anchor="RFC7413" target='https://www.rfc-editor.org/info/rfc7413'>
<front>
<title>TCP Fast Open</title>
<author initials='Y.' surname='Cheng' fullname='Y. Cheng'><organization /></author>
<author initials='J.' surname='Chu' fullname='J. Chu'><organization /></author>
<author initials='S.' surname='Radhakrishnan' fullname='S. Radhakrishnan'><organization /></author>
<author initials='A.' surname='Jain' fullname='A. Jain'><organization /></author>
<date year='2014' month='December' />
<abstract><t>This document describes an experimental TCP mechanism called TCP Fast Open (TFO).  TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged.  However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances.  Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section.</t></abstract>
</front>
<seriesInfo name='RFC' value='7413'/>
<seriesInfo name='DOI' value='10.17487/RFC7413'/>
</reference>



<reference  anchor="RFC7556" target='https://www.rfc-editor.org/info/rfc7556'>
<front>
<title>Multiple Provisioning Domain Architecture</title>
<author initials='D.' surname='Anipko' fullname='D. Anipko' role='editor'><organization /></author>
<date year='2015' month='June' />
<abstract><t>This document is a product of the work of the Multiple Interfaces Architecture Design team.  It outlines a solution framework for some of the issues experienced by nodes that can be attached to multiple networks simultaneously.  The framework defines the concept of a Provisioning Domain (PvD), which is a consistent set of network configuration information.  PvD-aware nodes learn PvD-specific information from the networks they are attached to and/or other sources.  PvDs are used to enable separation and configuration consistency in the presence of multiple concurrent connections.</t></abstract>
</front>
<seriesInfo name='RFC' value='7556'/>
<seriesInfo name='DOI' value='10.17487/RFC7556'/>
</reference>



<reference anchor="I-D.ietf-quic-transport">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>

<author initials='J' surname='Iyengar' fullname='Janardhan Iyengar'>
    <organization />
</author>

<author initials='M' surname='Thomson' fullname='Martin Thomson'>
    <organization />
</author>

<date month='October' day='14' year='2017' />

<abstract><t>This document defines the core of the QUIC transport protocol.  This document describes connection establishment, packet format, multiplexing and reliability.  Accompanying documents describe the cryptographic handshake and loss detection.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-quic-transport-07' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-quic-transport-07.txt' />
</reference>



<reference anchor="I-D.kuehlewind-taps-crypto-sep">
<front>
<title>Separating Crypto Negotiation and Communication</title>

<author initials='M' surname='Kuehlewind' fullname='Mirja Kuehlewind'>
    <organization />
</author>

<author initials='T' surname='Pauly' fullname='Tommy Pauly'>
    <organization />
</author>

<author initials='C' surname='Wood' fullname='Christopher Wood'>
    <organization />
</author>

<date month='July' day='3' year='2017' />

<abstract><t>Due to the latency involved in connection setup and security handshakes, there is an increasing deployment of cryptographic session resumption mechanisms.  While cryptographic context and endpoint capabilities need to be be known before encrypted application data can be sent, there is otherwise no technical constraint that the crypto handshake must be performed on the same transport connection.  This document recommends a logical separation between the mechanism(s) used to negotiate capabilities and set up encryption context (handshake protocol), the application of encryption and authentication state to data (record protocol), and the associated transport connection(s).</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-kuehlewind-taps-crypto-sep-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-kuehlewind-taps-crypto-sep-00.txt' />
</reference>



<reference anchor="I-D.pauly-taps-transport-security">
<front>
<title>A Survey of Transport Security Protocols</title>

<author initials='T' surname='Pauly' fullname='Tommy Pauly'>
    <organization />
</author>

<author initials='C' surname='Wood' fullname='Christopher Wood'>
    <organization />
</author>

<date month='July' day='3' year='2017' />

<abstract><t>This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols.  Its goal is to supplement efforts to define and catalog transport services [RFC8095] by describing the interfaces required to add security protocols.  It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + TLS), MinimalT, CurveCP, tcpcrypt, and Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + ESP).  This survey is not limited to protocols developed within the scope or context of the IETF.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-pauly-taps-transport-security-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-pauly-taps-transport-security-00.txt' />
</reference>



<reference anchor="I-D.ietf-tls-tls13">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>

<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
</author>

<date month='July' day='3' year='2017' />

<abstract><t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tls-tls13-21' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-21.txt' />
</reference>



<reference anchor="I-D.iyengar-minion-protocol">
<front>
<title>Minion - Wire Protocol</title>

<author initials='J' surname='Jana' fullname='Jana'>
    <organization />
</author>

<author initials='S' surname='Cheshire' fullname='Stuart Cheshire'>
    <organization />
</author>

<author initials='J' surname='Graessley' fullname='Josh Graessley'>
    <organization />
</author>

<date month='October' day='21' year='2013' />

<abstract><t>Minion uses TCP-format packets on-the-wire, for compatibility with existing NATs, Firewalls, and similar middleboxes, but provides a richer set of facilities to the application, as described in the Minion Service Model document.  This document specifies the details of the on-the-wire protocol used to provide those services.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-iyengar-minion-protocol-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-iyengar-minion-protocol-02.txt' />
</reference>



<reference anchor="I-D.trammell-plus-abstract-mech">
<front>
<title>Abstract Mechanisms for a Cooperative Path Layer under Endpoint Control</title>

<author initials='B' surname='Trammell' fullname='Brian Trammell'>
    <organization />
</author>

<date month='September' day='28' year='2016' />

<abstract><t>draft-trammell-plus-abstract-mech-00  Abstract  This document describes the operation of three abstract mechanisms for supporting an explicitly cooperative path layer in the Internet architecture.  Three mechanisms are described: sender to path signaling with receiver integrity verification; path to receiver signaling with confidential feedback to sender; and direct path to sender signaling.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-trammell-plus-abstract-mech-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-trammell-plus-abstract-mech-00.txt' />
</reference>



<reference anchor="I-D.trammell-plus-statefulness">
<front>
<title>Transport-Independent Path Layer State Management</title>

<author initials='M' surname='Kuehlewind' fullname='Mirja Kuehlewind'>
    <organization />
</author>

<author initials='B' surname='Trammell' fullname='Brian Trammell'>
    <organization />
</author>

<author initials='J' surname='Hildebrand' fullname='Joe Hildebrand'>
    <organization />
</author>

<date month='March' day='28' year='2017' />

<abstract><t>This document describes a simple state machine for stateful network devices on a path between two endpoints to associate state with traffic traversing them on a per-flow basis, as well as abstract signaling mechanisms for driving the state machine.  This state machine is intended to replace the de-facto use of the TCP state machine or incomplete forms thereof by stateful network devices in a transport-independent way, while still allowing for fast state timeout of non-established or undesirable flows.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-trammell-plus-statefulness-03' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-trammell-plus-statefulness-03.txt' />
</reference>


<reference anchor="MinimaLT" >
  <front>
    <title>MinimaLT, Minimal-latency Networking Through Better Security</title>
    <author initials="W.M." surname="Petullo">
      <organization></organization>
    </author>
    <author initials="X." surname="Zhang">
      <organization></organization>
    </author>
    <author initials="J.A." surname="Solworth">
      <organization></organization>
    </author>
    <author initials="D.J." surname="Bernstein">
      <organization></organization>
    </author>
    <author initials="T." surname="Lange">
      <organization></organization>
    </author>
    <date year="2013" month="May" day="22"/>
  </front>
</reference>
<reference anchor="NEAT" >
  <front>
    <title>Towards a Flexible Internet Transport Layer Architecture</title>
    <author initials="K-J." surname="Grinnemo">
      <organization></organization>
    </author>
    <author initials="." surname="Tom Jones">
      <organization></organization>
    </author>
    <author initials="." surname="Gorry Fairhurst">
      <organization></organization>
    </author>
    <author initials="." surname="David Ros">
      <organization></organization>
    </author>
    <author initials="." surname="Anna Brunstrom">
      <organization></organization>
    </author>
    <author initials="." surname="Per Hurtig">
      <organization></organization>
    </author>
    <date year="2016" month="June"/>
  </front>
</reference>


    </references>


<section anchor="open-issues" title="Open Issues">

<t>This document is under active development; a list of current open issues is available at https://github.com/mami-project/draft-trammell-post-sockets/issues</t>

</section>


  </back>

<!-- ##markdown-source:
H4sIAG1P81kAA+V9e3Mb15Xn//dT9CpVa3IEQI9Yjk1NtkJTsq3YshmRjqfG
m5lqABdkjxrdmO4GadjSfvY9v/O4jwZIy5NM1VatquIQQPd9nHvueT+m06kb
qqH2J8V52w/FRbt464d+Upw2xem8H7pyMRTnXXvVlet11VwVr5rBd6ty4YtV
2xXDtS8uu7LpN203FN+UO9+5cj7v/E0+nlu2i6Zc0yzLrlwN0wHD+bqeDuWm
n27oyWkvT04ff+yW5eBP3IL+e9V2u5Oialatc9WmOymGbtsPTx8//uzxU1d2
vjyJ07vbtnt71bXbDX15en5R/ECfseQv8Z1763f0wPJEdtD4YfoCS3GuH8pm
+e9l3Ta0vJ3v3aY6KX4c2sWk6GnYzq8IHP1ujT/+5ly5Ha7b7sQVxZT+V9Di
+pPi8xnWwVviL2Wvn3dV2eQ/tN3VSfHy8qviX7ddtbjm7/y6rGrapR9WfzLA
zPQ3OgHvh5Piy7qlwXAefe+L3z/jHxfVQND59PFnT9PhFu22GQC2i9tq+Nl3
NW0vX+3ZrDj3gE2fLPasrasm+57X+n1T3fiup5mKdkXLKPur9jZb2sXium1r
/HrWrjfbASC/WFS+WfhklfpmUXz55Gnx6V/+ki+VZhn8svia3l226xQqi37z
J/qfLGtGS8q3cklbKbf1LtnIZbte75JveRunm03t6egXs2ztT+irVYXJi2/a
dpOs92xLc9Je2klxVtYVIXtTlcVnzx4/+fjg0i8GQtceUDhdezqLMt3EsMFq
/lRiEbMFbzDZw+tZ8fXWX9f+tuKTso28rrr/KMc/3YNAazw/exue/9NQvZ15
P/PD9c//3fj0Q9umSz+77qo+fvn/wBEsyltaTXIETduty4GQG1f51fTFDPdP
6NFgJKU/IbJDxCd5sijefHH2+A+f/T58+PizTx6HD8+efvwsfPjk2bPkwyef
fRo/fPr04/DhD0+fxV/+8PGTOPQfnj37RD6EBf7ntlrEBcYf47HLHhbdbjO0
095v4jOMhaMt0hMLOmuCdz7PUPf4ny2Gv9/55qrspsQHqraZbrqWiGRbxwcC
Vd/U235aKvuYrv3i+q6HepzZals3vu/lmdc0+rr85lI+FcW2o9O7HoZNf/Lo
0aKb7TazoX00LDbV5tGan62H6dPHT37/+NnTp7PNcqXvKVez4Sb6Vz2tacZm
sSu+9cOtcojLa2IRV9fF534g3lBcKEh0pEjx5d80/KX4/8MMd/jcD9u6bu9+
7F9mxb9el83V3U/8eVaczohn1rSw4fru517M8OjnxMb6wVfN3Q8SefyGZvT6
PTPWAsCaPn42ffqUv/725elhYN/e3s4aXw446f/wiwHU99HtZrpoiYM2w6Pt
pm7LZf+Ixvvk0ZMnj4gwrMvm3/FxWi4WfkOXcsrMo232D+ayvS27ZV+UxRe1
/6maM20QzjwWKYrTbnFNV3wxbDv/oYfy9ZRA9GVXNY1f33MoxC2KPxPr7+9+
5Mu263bFF2XVXW+7frjnWMqbalm8ae8Z67RpSpILtnRwnTK6g88RHy6+2hL1
uxof3SfTx584N51OC7tgzl1eE7UlEWu7pnMplr5fdNWcSGEu0pEsUva7ZkHI
3rTbPrxfbKJ8R+RuLN+VQ7uuFgVTjHXV4zRBY9d0Y8srmoSkBhq5aq59R7PX
u2K9rYdqUxIC++amosmwqpkspvObmgbviXjTwSwGGqwviK9cFyR/XU1rorJL
WiUJg1UpP87pmnrf0FjLTUuro43w81gaCY59Na9qSCdDSzR+QV8K5aMNba5p
2UxgsEaS/QimQ+s6v9zS9so14Vf1M00Xl1IobSB+RoN3vgc4BwA3wCrCp6Rv
G1fVRMbop0HBcntd0kO9Lo2QmhdrYy39ja/bDQDCgAtk2Bk1JWhc+6ZYEXNc
0n8JO7FRmqFi7Gf2hm+IQgHchYrNxen5q5mgxbpaLmvv3O9wn7qWNou1AUl8
8fnFC3DLnwwp8NpHfXHx3dnX/35x+ebl6euwU3pnUsx3xZyu0BWIZCP00tmM
BImWl/L9t6/+JcWhYt0ufU34RtTwFp/LZkc3jDbWFm8bf1tckxxI794SjfVO
X+xpqBIAInIuMOv9f25phxWRbFCTvi9WVU0AoDfLutfXw6rA2InlM84QhuBw
CNlu2nrLJ0Ow7qs1HiFcmRWvaI52Wy+Lph0Iw4DALSgVkAWH42iSvtzJmhgB
+G0PeOF0sW3SPnoaGX8GwnWrX9hp0kK63umRPfns08f9LAM2hqrooBWSl+kd
O2txfDW0Lxnr6PLs/HjiSBheVCu8RZuiMZ8Uv/yiMsn796SHnJ0X17T9flHW
9ExH8k/3tpzTvbwlrsvblCWS9OeGa8Iz2j3dOXqpXhH8FyXRDzr5LaHxAGgP
ZV1s5xUJHnTLMPI1IZjnS79tSJIiOjHQ+N7RrSB5DmProWB7ADBBqqb5Sz7A
CU8H6a9cp8hGB9Z5mq51clD9QLcXNIh4yo5RqqM54ynvY1xPF+CVwH/tS8Kc
NU3GyylxdXBzwkEJRsla8MhN2ZHYs0ufceFyhuOkF2hLwKobmpVgjYtIcKtJ
MPKKwUDweJkZtDyX25RduayuCNMDZZFTT66wrKc9sLdiXvZ0nIJfayLT/aYC
vOh9Oq/qqil87YWu0B5KXgZBq2uJJhJcXgOIREKn257On8hQBSIMiCv1i0gY
YHRD0rbQ8tpHutdP3C0RVrqf2yvaNAjBIHi89rr0dTt4xbHhugcRkTcIKYpA
xjG5yyb3tNSipfc6vuOELXQhp0K32zlLIMUP1xUWozc5YTWEiOttY7gBin1D
cj/w0hgZ6Tn8+HW79rj4S+Fdcl3lQMLRl4nAEdnNa5uNL5n/iXgF39Sj1+e4
mnIPIdq/f0/iJr4DIbILu+BLIIclG6aL5OMWinwLgfanOE9bcZttR8xFOAG9
Qq8qCyTSUpHSrRdmvNVDZ+3CWQ8qASullYPjjd/SIrHuarViBo8DZr3M6wME
O9ogsNnNCX3p+eF6YpyUEXpBnJ+u2nIJdPY/6dnpnoXI0XoYYB/JNWDi7Igw
E7qSdoBz4l311bAVGk84fdoostCymKKUJOHTDADagLuGB4l41ZAh8YPS4Xiv
id4viHWouEFgCUedEenA8pXyAyQ94Uy5lN/oFtAfTokkRKsliTntjqUxmpQA
AZkEB0j7vNoSIaDX+DhWNBTzODq/CduW8BFMSmgTxr/q+KPiKi+EBqUzuCl7
kpfoInY3nuSQEhYXxkFolOAF39jOmSZC/rLT5PXRhtOlkZrWtHV7RQsZC+Cm
EREP+ubieKLyCGj60G74NhxVMz+bMM0oC3qoqKt5V3Y712/pVhPX+G7jm4uL
b4RIbnvfj2nfMWESwa/TX+LKpnyAjlSnZX9dvmUqc023AjxoNSg7iwotP12E
pydKfOhqgGOToJ/Iez3pbJuAq8q8leKsCggtoB1Etuh2QLPuqg0TOuYcbtuI
msNUhuBKAkNgWKk8MmPCcgUhkc7igHzqZB048HWJI29wllHC4quS8ErhaExP
QAGM8PsVeHFPzGHEhY78jLjVX75/dUY06g5Twvv3x7jCa7o1VyXTb0g9fM7h
BtGlu2yJuTLBAEGNzI/AnIrMnsX9aRAzExqWWJNdtCYfAQMmQXdh4WbpB6Lh
gvi0GIgUqkZA3UkI6dw7wn66WFfg+HtsW65SRtOrhq4AkQ1abRRUMyFSxmUp
k85DOBIoNO1gXxmYEPPqKzoOzAsNhh67cgnNJBSDGUklji1YOakCLJcmShIL
/50/sAXCkFpxdk1oRgtbAjuXu6ZcC2eZ4JKBNre9QI95+cvLL4ikxut8QVQD
rN+Z6YMN5nSuuXY2JqF3KAhCL8viteiCLtMd5NotSEyk1fYetxVC+ZVvPKFu
9XNQmZjeijyoMq/LBGETgGkjTN1gcHv/Xtf08i/np2dfv7ykGXhnM1uMcDyg
owPIO7/wrFxCsi47kva63tZINE+5M0MjjsCSQ7oUmD4xEtOlWfEF/T4nFgJL
Rs6LSYCulkTLFgrA+W7wJvQm0iGJQARzuTWs+BKANmXF1MdWMWE6BESBfBQG
nQglBXzbpmaUgKTvl05IwuBFk2QqS5iOw954pozQpJqqv8blkd0NTJmW5VAe
RAVitHwlWLIUkg123kFUEAavcoUqh4oXTXEaNXnDFVJIIB6aHMgcg8gfxj6H
1DFzr4yiyXuY4Bayrthh46FkF+SoP2axkF80loedOBar6XUTPAhW7Zbn6xck
yah4qPTluRK2TDFpvBdNcV1unBxAzQaHKlvptIZ2D2AAQXpj4EtvggWUDDa8
rGG5Bjhdf12JlI9nr+othALopXMfB09e3+FR4qgspDHvJV5DLHZF4mUl1peV
WdP2YTQTI8BbT0/5MpgT+LzLXhC4S6UgGqlnYGYqSudPnJsWL02QU0QlVlkZ
KNRGsyI6b5sTMxJkiCAA8QVzRRggvWowZhD6JOaqcO9SywJptHqzu2kPcZpJ
sh2csIaCSe0wXXb0mAwc1t5vNwwi5tsQmeWO2qKjcH5AGSzEEWLKbspfep7l
m2jSSi4Ckx0i0iQhrTwLE0zS1RIxh6CBhdP/+a7GgdMccfbEbgb9E4oOgNHn
RrNgDBPzlyw0FzyABXSdiK+XLH6TzMHKUsmXv9+uN0afM71EsFrODSiSXwEj
58ATjBmv3ADBbVGKGp5IYCQ707xEjNjsUhRwFpQ0WV+Y4Jg8TAeLkxE969mz
Z8QFsBqQtenQTpm8QRnwP98QxtBo/CR8MiQN40Qu905RdIBEHgAzj/h1p0Dg
Cuaxnni6bbr3a1gdFrBZ9kO0n8YxiIO1t42KLiRFe9gEBmBo0PZSeraNGr9Q
QAghhGSEzmwFUASQk8N2s+VmkktPu6nDuaxxGDQ6r/wAYrNLIdtboBf0YYcn
b+iyschBUEhkypH/jMF+acTV9Ce61aCyFY/O0vLOl12fGWgOiEBgk7hkfOaJ
JZXNeRVWwjaRJQwORoQjYD9EwiiOLs4uTZEXMWPC2s1rdnnZRg/7wehZljTM
40RP258YhkVCM2/sb04MXCYVqSSf2aGNTMPYftjo7H6j0bm41+jsPszorCaZ
NW6rPsZnDfSfb6saggdsX0MYJc4KxioSfCAjuk1C9rKGhg2t7KrFXYQNH9Bz
EGqLTH41DYdNCBNWdCaFaKqklZTd1daLtFRG4d2lNrao4hOhWzGXVUsIOIyI
BHombNT0+I3YMZa+2pLk6EDq2opVHxLfNu0gav0MdvjTzMpJKHJJV6sSXdu5
/xP+JU6g4uEf838P0x/f4T/GNfH5g9+Mr/9b/jH9OXkBkuPRMT/xjo/j6Jj+
grseBhN8wC+w1vrm6Hhvpr/m4/91/PN96w7rP/zEPkAO/HtXiIauWzi0w/Cu
agXx+3+e6j964hveIX49+O7+vAefuPecfst+i3dPDkzQ7C0n/+LhXYMdfD5O
sffjQwVKS1rTaFf01B4C3r/Xd/eubA857wE6rWr/9TMY2a62Sizf8cLxL1VN
su39w9aiqPNGFJ6/E0r3r2z/L/335F2xpL2DJ8D6T0KS10Ai+/dQV/rwwF7e
qfzIngDwabYLT/au+WHw4LtNCwHQqzK0QQxdURx6vznwfvNu/OTDe6FiYPEb
Eo5gZMjxefT/hWJuZIf/k35juQB6THqErJnKfqLxu10FmVrBlM0mWPUknS3o
zFDxf/PWUkbxy0nxO8LqaaamcmDFHx/scZvO1yISXlcbFgDSsIAH71XhrxIX
E8mLazA+1cvTWSbFwrPNGwY11lWC+ccoqCvNgjt0sIhBy4c0UOb+O7VtNjEM
h33Yl+xaTVcskhMEXjHpXEOGpm18gWvtScwaQ0LVAjEfmjEM1kxRI8CTfzde
dPHL7xbyFwHkdO/XI1o/+yV39tUxO5kOCFOiUUwTC+MoqMKsMdEsxW4+Mzpp
wMMYXOKkFetJCIZ4rs43dt7AHN+UJFRAWxapX6wxIy9XHjJwYauJejxcxGXY
OmytrDlDrh4pNGxBq71sY0Mb3XuWxrgpaxP9amiXm5JXJQKZKK/sXTMrACvt
iEtcE9lawibMtwx/MhHBT8FbmSxmRqSWl6F6BhGbtsNI0YjwvLji1bHbNFhn
1cPKOJpaHF49+s7MWyL5LmBr2aiNd545xaKBF25JMdGmFhyOkiEtf7uei3Ph
ttz1gu3BnAztTFWrXox6vCQ8ekibBAg6fwXJpHOIqaCZb8uGnfbs/2C3LWnv
KXrBbyYibTRzmjM6nvktaRjYQWo1hUqwaDu4+1pBGXu6HDQgIrPswUDJPkVY
NkxirkhUpttdcUACbckCc3DKG8VEmstwISG35qlP7CJ33T3sMSxu0IAc2GlV
N1Qt5q7XlZofmQGidFABoxniOazZRHYGYxVwnYC8lJV6I4oHoEQ3/sFJvNZi
CHcM69wgjetWkRYb14xnOcYFQy1h9myGByeC05iJY6Wgnzu174w8mIQIR+DZ
ObxSkYf34H75JbEa0S7UZBkQmOUGxjLeT8l3EJEh6a7EcHVgY9V67ZdYVb2b
BZs7PUoYCfcF7yraqD/gXEHRWXOyWAsOQQnbSwxFsHHPETVWszYpqCOwq5po
Lo3RYWy0SiRC3vQ0GKcIJo5VzOCGXZRiPinZ8WDWx3B/xI2D52pM9FEfeD8t
zcHEdUUQ2jakNrLhvN4dI5K9Z4fuooZ5UD0ncpGXB4ivOFsbx9ZNsxMpEyNs
GgYPGx5YZ8vGntJ+VLfpJpsONr9anIc0se+6tkM8zarIKN4Io+46qUlCSwSX
HBEwun8nBbywgzAcOCkDDRmh8OhXoTB9ufZjFihRONH2ppxmK6xsFSNYIgYm
kTQ8pEtPnk0PEchTi96AoQNcOeWLsieQ/P43kUa7IxAgMAZ7vj2CJNRXPbj1
th9UeU2jF8XaEK2mKkLdxnN/Pd6vM4EiC73JmFPgY/AjpWztkCMS50tszlds
ytr2zF1sUjNp7vnjE7v1BISf33PxPbbO9eHAohn+gLVK3ND+J7lGkRgp4giL
3+NGI3kKaGl2DBdPVV5G5JsOcCTEXj6pZFmz4qu/8Acink5COcCsnou8WbGx
DkENJAIZj6VVMG8oiLM1jLxAOHZvbUk2BLaVtQN5YWhEXyWRNETwTexCsscu
nJRuxZyUiRsEShuMqj147Kpqone43857i8GdexLECLDFNNg6OLj6NJo+WN7V
BQb6NxaUBYFZeNHrAHEEIymOi3MCRMCPLjkbHvcchJM9oZbpLUYkNBLLU3RR
3SfrFq8QLl8usey5xzvB2cKpInbT91cgQrY8zVvjhQgW6KnvniOslUhxJ+Sg
KIpc6pe7jFnTG89IIkMsxA/DjA0vyE1fEe0nVoHxDBXklC4IXRZez0g+fNgJ
sbwhx5QJJ+pFZkhwWAQHosA+i9Vsm8yfnXkaTFDim7uAiB/cyrxcGlEWmMgL
gXbiPgUHqxI8/GbbrJq3tkn68+/fIsZKJNu/Z5uC1eJ97Dn67u1/YYdv5JqE
+xY+/5YLB2qmSwlbxnB8p9h0o0jdy0FMeLdCZejKyCAjCslKAGOF1wsHzTWq
DVXDUQI7Fq1jMCtjIs+ro4YlIyrb4M5YcWlU0iJrRt5EpVyqNePa86wiU00j
IciDrRIQfhQmJMoOOhAWE+ipBF3oBRJKxdvE1ioON5/F8X7r8UY7Q2pUUDcY
4dqw51+N6n+2JwO6AxqHkBE1lNwgpE8tNkO3FZ/NJOBrJDU0qtNPj4Q690ms
uj3/1eXl+fN06LrsrtgdtDe0RORDDO7m1YB4v6KvfmaJWqK9+x2R3PVzi/ne
Bn+Sg31EpHlwAgSRIWw06FwWLANavRs0zSSuta7eenjmYsi3xhUxTk+iuN/A
27nZMLU3yIaDEHOCcAiG53znRhLuSANJvLEno2DS8CTuIlxpRGt6f8VOrUCF
aMZHuHjtek6cOE2iQei0LGVWfGWcpLQnTIqWEB/2u5p2ZUIjX9dFCUm/GlQP
7UU0iA5gtb1A6wreQoLhmaR0md63r8uptEfznll0EW3jvOzg5ArYOXMvfFkD
bCyKhUejpeHaoltgCiYlQ8luzM3gpTG9Cc7MTF4/cDTm/y1r2FRi5g3ssrjJ
tgwXI6qgwzJli75I5rvX5Y1nzP3JIxTzp2q9XYcjEBwFjBybrZQO9aIsCu0N
OxW5GCFQcLlj7CTsZQ8ws2iGy4yCYwAXR2rOmKRklaNJNCuP+AUhZBDIHeLa
+oJpfV2DUPfHB2AlEjVDK6GQeugHTnySWexsaqQ9iXHOIledcimhkgKvaOIK
gV9hbQDl24ZAG8wCKe9YegTTAGfaztHj9KBIR5qJIcMnIShAZ9wHUYyTOTaQ
ytLIOCJI8SwACzvQBBzDwTn6xbVfbmuvXAyQUgPCXCaFRovrVt53dbKMBULo
VTobwifocqsqryxmjBoTV0k0oIixoqpzgiyhMJsBM5QzbK7Gw4eN44YsvMQ0
8Fh6HaIJUwnzr4ww3g2bKN3eFTCaDVWIiDZpTFtJ9hq2jVclX0CdhPLbVBHw
4Ctgm/rutc8NgYEvlByF0/l0wbyfCRz9fqGsL7FWPNiQQM5xGvWDKDMBpcCN
e7gizGwG1o1bMD5FSYayyx14+gFKWiA4+y1Er4ZtqBy0Myw07dGzZGO4C31b
AJSYXByTsh6mNs2SJqIHZRGgC1bhMJ2EWpiRWVcslr+l/D+SJp3lRzrHxpC4
l3KPpk3MB1R1kULosRkOwsiBLI94sQ3rgrk3uR+AXvYkBB6FMZSlIGplkAZ1
UEFzrRIdEGHeaozjYW9M0P0c3V2mgqpYpgKyQctoHNtsYnpHP7Qdlm5QxRod
i0dsN9TVIuB2fPgpG267xKKKjIUbFnNIHJGoe7F5iJUwBhOHPBhO3zMgitY7
NrVxXDFbFEIAn9MDmxUvSw7iruvATuOCxEYdL5yBip4A/JPjkyO5tXvqLXRR
E9TymBqTAOR4FF5YlG1j2Xo5YWXXYASNqOcTOxQRQ0EEWpFfNTeNU/Fw1tdt
zQBdk17U7WYhBkzxQ6UDEbNLiydzSvWCvSqK4hL4gxBqSEkqboUTZUBvm2Sl
CHTOTckcu5QSyipGt0YJLlwIUo8qwExFDQBozFSIP9lNKmOcbtTrQsy4hf+G
sHFndEZySQUIX7z6FqmE4/h6dRim4iKrfyNNtTeDmflZ3x/TaN81dgMnEVp8
ronvJ7oKD/nAjOHB7KIpRJpMkaenFeJ40vh8tqjytJuuajXFaunXHLqlFMip
kL3Yhbjwzh/MURHzWX6D+XYIipp25NLkOeYfKgxxdpwaHULFkegkP2Ryd/uq
ybUAaJfI2eo+mOT6U7Bqw7fIvKP3atmNS1daW7DyneX9tU086nXg35wyLH7C
VBljk97oYWYIZdWom7PUZG/JbOOTYXfDAGnsgC+Q+Fe9XSIMnc2VEkbNGGg3
4E08ajWrBJ5T7oxuPLAI7AcFyikQLKBB1S08TRYwNGcnsiWwXrN5LGVfzO9D
qum+U1pyp/b9ACwVsdnRFpGYFtZ+mIy537Lq6eIs5a72bcvpNEF+j8IEjQi8
R4pDDDAPVzX4XqsDjp0D1n5YQ9ilGsDca3Bm30p8MpNVvkCguIFEC+5AUmA7
T9TGI3+UW52TJQVAwuZDhh/zHi4iAuu87e05s1f/UwnilWpFibIg8QwhZ1Fh
4PPgH3N5x/c6f0UAr+G0g8yUTDorXqTeakWLO92WBiezioo4nYhJ42QAtmmp
/xeh4qJFsN4Cfm35fvf441C7TADM2dEIirK3+Fuk5OO8yjvQjzUJRTlO44h3
VjIS8giCKlrW6TiQDqUsaS02znMlsSfJ9enDNWyqhUcBIL2GRo+zkOlAOSLH
UbCzUzA45bQuAbNYgtk1fYmY8Z2kv8a8yXHaFUZq2mba0KGze4Yzb+FQ+xzp
squSFOqEQ7EHrSls5UQ1SKoqHrP4cV1d0ZGyddi2Miu+zZ98kooGhHi7ytd8
wuMRs4ud7T3b+ESff8reFZlCKy20BUJjwvxqSDJ8rUtNB0/gLiinF4tIzFbU
pBz5JOL6xcXZOcZakFokoV7HUqADvDrQBfVL1RrHpfmsif11CKK4SBKpZV1l
xarRUkJAMi7eVbNCuNY8PVop1DAxDOlGru1kCXVvfGPWB7CR3Ul8LKQGYy2s
GIRTYG+f3hAMhFgkPDo7xFH41TJ/OblghNyZPIjxGFe60anvIQUBEy5U/Y1I
N+1UDNa0MUl8F5cT6l4IS0XOIO6wJetG2sUX8kXIdrmLPT4AkV54uKbkYso9
DDtom+isZsBgwJBSaawxUlNlpAhNwXIeaBZb2z04lnRefVAdA1Exi2SVs8aX
RGdqhIBMAtQ0vzeud6K4ZlBOJapyDtaoeQgxlpO/4QTEyM4ngH2IOVGbVPQQ
yE6jUnJrEMEwAuZXUaBUOAd1c+SKhhyeWqb74kGQRocHLObKrVTDGg32AXEY
Gv009Nl8MViCE4HkAPtyFU2mXC7HSi3IIFjkyLocxbqWo10Y96Tqo5YDwMV8
PH1zifRcSbVJUsskeQixVV/AZ4gCAZy1UTyZ/V6OFIkcxwpJk8T/C3A0S/l/
GxhV6xDIqIOR02eXB4zvyOflsQhhJinnvC0rC9eZe3MRLAMSj/hgiwCebtBI
R3o9ATnvN+6mD6UkOok9EBTmA1EtSbxHNvixxoVCaQvqAATdJDqy5pRFKUTE
1weVhDgUqU8i+CRhTI1R9NtJMMOFI7JYrcRpvJzc/Vhm+DURyHiFqv8HXiX2
UEUy5NJU00fJiJJP9m0rxqW78EHpswrQ8AYoBekNBOL7S+KKUK4kizALGhAT
Zwvo04i0LMHIpsn8hEmcsOZhjMJRlPu8ORjFcuxicIO53Li0rsTCpgRzotoW
M1ZU01sWm+2cLgEq6jIaloQTcDCAlq7EFDQZV7nYv/2IE1qDtvYT16Zpm+nk
7NrZipM6kvCQ05fldjjdY/alVLWIbFLlDKulQPrEHYm9Ft0Ryh4lYSshR0BM
Gm4UCsrJtygZaHfgud6/g0yIWY6V3wFJCvnEQauMf9mZQ7K2M8UIYktBYG8w
tkBCjfEtGe4RgsewG8Fl13kOEcxxVIyrOwtFFMNNWpYOEqhgn7n/EU6nOJcL
qsxbNTCq81PNPh1NyEFZwUzrnZjfReaTYKEAe+w3TXnGq5yvzsDGavmwlkEb
DjFeKlCmdTSqlWNj16HagdElTQLmtL/mFHlkTyP11uLwQAS3w7RdTVEDCXHd
WxTRHi/wwLIkgE9kcHHAJSwG5kQnwrkHdQvevwObyibD6a+3g3iTUjIkexJg
cQUxOSWulSa6tkl1nFdAJ3mTnngylHiGkrugg3KW+gE4cppMK3rT6NhLSwWd
udf0RHsje+UCNLbcudfBOV5RazCECjnpaGCA7ZI5kzOps+l9J6ifnn3MP11K
levVLkkeiqlAdNocrWjp8gEcoNvIPQflTpcgL4T8eg5IJ3VjDYqumJ8+rmHI
fVSdgOr5gYo/BCZmjwyLpQv3V+QFcxiN8YtEXNAdyXJl7BydTqiUxF5or0nO
d9cTfv9eZIyWTaGwfvaBnnGSDUeAhjwbIQYAgJKFoHnnRF1lKKkEF8JbQ0mk
koNXkhDvUKRiVXZqGxqh1QkXoz7qjycWfH3ke4lxPxRiHhlSESqrSAWy8Zoi
Zjw/yD4k3vr5fRyVZDauWR2SrTviSTcIiE9vWJhcIgRXJuwIeW3urKPw3CWa
P3twMqreH4i2VhFVzii4/pMCDhoak1KnI9aIDOFUFEsCUZloh3QpSAouBJPu
vbvSJLAYistCgoSoI1aWOZwhkV5g6ME1R/EJ1dIgdpCYn33XFoan8pbKuvgm
FOXLpY0vMlvifsAwfNcjZEhxkin1rZ/3qEyqZ1bJ9sri+zffZKWVdR4UI1eq
RE+4WzPc33YocaYKhO46T38qg1/O4pjpK5cwOS8lFPkVAZUUQ11XV9f4ttPQ
CJqXs6xaUjfZgFINQllLhxs0ydPc2LoowuWBW8Rmzl3ATFXCiQe5nibQ9aeL
kQ0PwIa6bd8W242lBGrkuN5dn2Kt09uPepsQLkx+evHthdUXxbEj7jEVS9Oi
kLh4L06/fTlz38HvEGAc1BHDLRNtJHJfjdZ3aQYcnxeV5BDnHCiGBRNDIq3E
zyGBvjadUE0WqoDvIl0lNFMLEtwhTorUGvIMUj3CpVR1zDDLEObNIrdvFkT0
t7XEUcAyAjcVRHic6IsWJNkdnd+8ONYcGKEeSaVErcNq8f2b9P0lv58VzNG6
hc+efcK1MoBdy2V/xya11Ffc5tEBzwU+CbGfgAcqW7u3BD6mznljDOl3Rzki
NcuUiG46zo4C3++Po9g9SHkWTVThg83T0X/5Xa6tcOJa9kR2EjlF+qjXKDqY
l3pLx4WcnVSLk7RrRdF2I+Gkzu0xBdGRS5aqIBFnq9ATSdULODy5LrSzmPVM
oLkuNf9JjNTpYFqFKiWt6npgqW23r9lpGmTgC10m0bZcKpEvVe8H8aux/KTB
ZbppFvZMWAJfnQjRGTM1fszlmQn5jGyzKTmyyQKYM33dN2IxZ0rh9GqkqX18
93HbuDBSJwamYH08cGDYHrTgCUYLu932W3ZlAHRp0GMEY58ZOU0inBNRepsm
zN3AQ8FRb3TfavHDcsZ7QKPJHph0HyvJwQ6RfKn/feIS9JxogIB44XhTHFPR
MUWIdtMk+KWWUrUiV2Q5WprQxiHsFqCVKCJjy0hqCcl5PAflpZiWB9CpHSmv
Oo0t9cUP1fSLyorEQGFx31y+FBNx10rmEifSQ/1AdWb8qnyNeO1WD4q+KZlb
9qEaNAo06xVJtxwqpmbrJRLAB5XRAaiq0E9hHsSZmAWbL2vAswSGMEZG8Gko
WQaWqrdABYk9bjZbTd0EJOPQIYYEeTnMGgLDlVkt647Dwolut/SkeUTxDhvw
NNktLHW+SzDpWGMBeQSQQFSY2IlBbrXtWGw1NBP1IVIVhpUlBIM1rTk71Rmu
TTSWRkytJQeOBOdADpGjvTtacmxUdYWA9pFl+pjryfMkwhY5KxXBT8Q4wDfU
Y5DdwChYZMRcp5scWFMSVOGdib6sT9KxhRpXF2zRzt7sVUsIRsxKwoG6iiOv
V2lh1KmooqP0vlEctd5hVV+uJCyM7XBmwvRO8d00juixYbFtP1LFmNdISHdj
GECcDFf4Fgo1ckg4UB4RKjEdbzK26p44cD5BASRBPHoq1hH4JOQPRGhZZKIg
iTzNpXX5ke9fnM/cqU7JMaSHT2q8yn0Ds8UnwqKWFKDHHrJi3BkWnhRxC1g2
D6M+FfXESLm4pVhvUKK80oLm8MJM4YWxR2SvBwYEF5HBdBBnvCUbB6GNdx0j
D6RS4ojWSHCPas/EV3CbYiV9KbfscjmtrK/gyr1epwwenMNEuyR5VKKdgjnO
eJgUNQzLzLR5sclEqIdFseMZNycUCzDek+IMWxzwBWeY9VqejZ1bE4uu4vB2
jjKIaw7TtIfghHrrcaPpnVHFyOQdj1hqyckliKJTXQZYxJsYzBMZV836WuA1
+R5OACaSQZgksTawD0iw0XCW6i3FvBKXXWTPIUtar5QJVhbw+Sv+uFj5mssn
9GO9xuihG7tXVpKCc8ibkvUomKSaWxwumgjjcEEHOrBmDUDScuJMlVXWg4Ao
GceiyOBCiI/+dJQ/L/lvfNRBqUpEnhA3zVEZHMGZVcO9q8sAo20QdEL2tngl
tGpuK1ScGTwyHj68DICylQhC3oQE/TGtjekhtRYLObQ5QGCkUSTVIvIpn0cI
hLF+SjLyRVgL8btsXckzzsOAYMgJhLuQY6Yyt4FG4aG1NUcCo1VBcexIsQQB
Fhsra06x9PPt1ZUFodet/G19HuSCsVpHWMEizB0mVNGQE3czs5DgWQqVaiPN
cJm1MS1oqvElUkcJRYBNO1LnVCoDSIyji4Yape1QV+U71TYG/9MQGeghm0Bi
BrC2OSNHXAgHivtWqNa+7LggvPWySMxME4dgNhw9h/6m7kYNCreAJliQXp29
PObmR2tfQpfTwLnybShsdCdp4tHBeJB5ISICn0O63rAUq3bbr2fulep094Vj
GvVrE5u4JBQedX56HAw8Y1exZSCkPkBRMazCVxDT0yhbLk+xbcxVeu+iuHAI
eBvjVVqNOElnZHN9a8V1FyCEaYWf9IY57fzBtDXNwj6AeTmzRjvS3mvwIBMy
xymGxtnNK8tFrF9rUlNWDhb9JIuj15ffH0uOp2U+hdyNEN4A/aPcoQ2eKyAD
zKUGWR6JGdQ+CSZr3uqqgQLXvlwepwmcSGzlJPVVMMLafeYwTISedjHGXqJZ
QvZqHqM3kTo0KAwcQ5oUYfhB2mKCjHoRkA20bfaRkBc9Q1lrbZfxkmvXqKvF
CtmAy01RsEr6YcSYP1Zxii/D+RZRo5zDkVdLPmxy39RzdehC8Fo4hbvdMBFG
vWKL7ZEXMkjwslu65CSPzjUu/I71b5In2LZZtxIAjErrhdYHSU/k7j3+2g4B
g9+wx1/d4Wm4xS+QhvIGnPzwJg2jOV2FOX7YhCt0G6/VP56im/ljsnO6a+Wt
lPSgAQ1LdYzRst94lW3CqtGNeG2RQJ39HBdr9IwPw+W1PMen8caaypAAau2J
dEwL4xJrcmWB3B8i2NCymRO/1KrFrz2SIlGv8ARBf+L46YTyCivo2H6qvZgS
YAMco+pnbEkpN4KFSXhisjDjwzn9k1tgKSWwPnN2GRuIDpNZTvCbQh6bMTWo
JM5BQmT353UgX6ryx35BWDNrQUzcrAILTfvcWutM+BapDRDKv49oKSvSTiYH
gjJtq4tM+5GqC9L7j04JFb3whCTR9M8zLEOOl57OPlOz4Yd2w5vhtCyU7Ymu
zyg8py6LyV55xrFAlCUjqTsZsfVzDrHN6iYlDbcOdtoi8VvtR7hDszsL2fex
dpyhgVw+DSzUzm8uj8UWq4L2ObSnOSg3ufupBBMIm4ZRhnDLWIUzq3x9uIW8
cz94TgskcIZUJ+1mJ2z2UIvSxMuUIHvptENj9isqm37UjwuYWjBYpLpRKJHp
SQcglRgnI2KCtKgVpsBZ7p308ECz3sK6Q2pvydNUWtE4aFXyUDyGfZJShN7c
SFI8PZPktdA+N4bwVnVPvtKcWcs3otW2mmEbhkyHqroQWiAQRncZQqsyhsO4
LDOWo7PVFvEgAaeFdKOihsy4lo2yyE2H9fnFC2sOOtHuGfTGsmUCCIXgSntm
llJxYMr1OjchJiFrIpt3qjUnhRabN3WLlp63geKcKC3FmVZgTXOlpJ8OB3CR
bgdPOLtTXCgzUcXqgobXFl/6EQwFuLtSurLUkN5pTzcXyelJ50t3x2Ymowqp
WjqVW7qVCfBC69FYwFQKZNg5dH6lHhKrX4gaV+xaI/oElWncmsOFZNJG2k8N
kh4oXnpwJx8BWQewsghMB9gurbiaMxjHWg6HiqdKDxeJZaLTiglGMS7xHqsJ
L5LZhEPXuqSnHtt6Ig4kxujsyDl0aBdavJBQy1kcSfu/6N7iXpI925RajYqw
2gnBtWbFKmLKRYF6A/R/hySGPtQ/Zf6PpYYmGlKtSWLGD9a9jO02WummAGMb
QrSld62hQOr1yzsoOLZy0K1HX0C2Qd7R6jJjaeZ3QgfGQIktRImdiUYV2UOw
Vwg6mHNYoXEWNqpBPqUVVUDdyqSFQBtKUepvZWENBZ6LBYDLQEkwKAtyIYoo
KTPVpCGtOrMV/+caAKPsemfLShj9uLwwbTJsCTd+HdvZmI1Bu9VqP16jlbIk
zVcRq65VkUmY+pFlIiZJvSFsz5KT2D4kKS8W5ZRUkrFcWcu3DMmOfK0sGOhQ
ldV7yt/KhYFVFTFXX5iNOwl0us/DOqrqB0QxBKCnQLCJUe20KorIunFgPI1y
pMusCFI6ntV0YRFN2lNlvuFqFXDc1AQteUVT8mqnuk5utCb9gzpRNsy4c84+
xTMxWGXRgNELOiQ5hxbxNiu+UA9kdHJOQbxGI6rznA04a4lPTVK+pQ/2KOvI
QokYHRiCefizNpYBH75jaS9h3hpbyPMb6uhVdc0SKsB2kdVeSnwl+X5YuUGK
COLcSMIB9ymDhO3KoDBnhlEcz96BGO8loEixBGFHYhYR8xiSn4VHOhYAkzq9
Yv8eR/Go5THNOAwNWriFZs2StdWFTg7DiUlVDOeJRkbQ5NumeefGccfhqWW0
Op1fvBoHjCfB/IWL98gcouOwZjZv9nwXzscWxRDyxnxxbWJd8kQazXorhWwx
UkhcSO6pOhFYW1iA82p0xsUrp0EDR5mW6S3jVW0noW65pvjBjJdAppTCxEz3
hU/QyL3K8lJXrzjiwMVjZFleHlih7mBUIJ/PAJXwkIiIUMjDBe1ZerBIARB/
1QS8lJfgoHO/ET3KhtTLF9Q1N0THANaLlbPyzoWMwTXH4NXSr9rTSEvA0sYV
2JXWvZ1GN0QWc4HzDen6saH120oCnzmmvJEEVIQVqtPgpXjJ4Tg06J9rMVjn
vvLQYYnPh25SXgNQtHKySVjmLcsDjq2qLGdLkVSFW8tVo6NMCTM9aycmovY+
a11l/lMJiAdkKu4x+zvEyUmNxwup8ciL/UjK6eqesiKQeRuAS40RxPkurlEs
JlS/x29O66sYnhhnlsirStqwcr5fqNOsgpFVcmq06YR8fv/e4ILKiPmgGo2K
AoNo8BsUCaFcVVoaMK3yY8UZtbBZZKVVo6gT6iK4V1GSQjywiEwX3LdJAoTn
qGgBIXWoarUtxVg0lpK0tvss9hhxjx7ZptKqu2r+DH0oYEgp+nL3FZHVlub7
hcs9hAlO/liE1bEbZ6IvHmfPzXi1P/4NBT+OHvBY/+PB8XH2yBtuPsXzHa17
GBH0dmNS66GyWg+zc0C1bo4QAdRc2aj0ynFsT9V5tjisiGlxLmTxPp/sDCLI
0bF77/Y6rlhpLOm18jJDRvRSSXAvoIl8BprsSbAm0omk2ifpWyaKCkVPD2EP
wXvjzlZji8U1Q+scjdMDhpk/nKySbONXoagVJpBKW0O8R3Lw9P7rndzQ75oj
O/QQ8P/Lbz/ADCFwZnY6BFlasJa+S2qJc3wdS4n9prxtQpVYJZFrWai8F6lg
f2ST1qZJEKrKmQiiHme/zk5FkcBg+/uctyQ6xz1ctYcBs4d+Q7f1cX97mKbn
MsI0+dYwLdYKThqp2IuhfAhHbrAhIior7FgIrXQETzsbjds2hgUxCIEG+blN
tPovyh4bOPmb5PRombpEu/8Y53h/s2Hq8X7DD9jyHmMQMesrov674uXOz7nY
Ja6OhjplzUUZYrSZZclGkTo1NRppD4V8tba8VplbMVvDLF5ncWkT0qM0ozQx
6pqQuWekNfUxYrKT3qbHsXT8qPFD2rRpbNopt0MLOW+hFoKV40H2O6dWIe5T
AMQuFU0cL/vMX5Xl5Wt4/sdPfo8Y+SGyQrZEcM49h8RtB+nVGFhqH2tqDb+Z
vSjv5FSmdbrknO/8RTLf/j7287q/OvpuOyhu/6IFcU+KMVeaxJoOSGanK/we
hSjq+J9/PN/6uxgXX5pzLwSB/5/vzLdqqDzVtiSXWgwGqBgK02UilgpeRjVI
M7pRLUXVN22tJAZDAzyLIE6DpvU3TtlhBtd2oSZkpFoRMTTWI1zKOUuoTko8
a7n959HwEEoV8HQqclt9/sIaaMXAD+tM5pIvpSjFq7OXWe/gQoRlqZQIGHIJ
Qi3iMNor0VgiAGXjuUhCDHeR3LTgK5Nu1X0aBTcMJRuReeEujQ/OAzdwoq9D
rf03JlK606QCfyh7XvVZqw+tSyzF9LMZNecoJpzIg3FI62ATKr8kpVPjU7if
cNWorB09Kya4q4i9L/e2Sc5QNqHy+D2epG8GUASu3mNzf0SWO7aZcnT88t9z
J+/g5nxYqRr/edsOUIC4JnmiheFWcQG//cRgayfGaIayXWlSu1195m5XLez+
eYuNGPyYjpxYToPMuc48/o5Tp2BOC44Tth5kbZ3OPzizypWajcjatawxBEAn
ibKJeT3WpsgKT3CWlZOSPwcqT6hA3aXp3QoMpRNpD3X2Qc79VcUOmZBNomn+
MXx4lBxs1eIYInByd1k2igssLM41Zn+ypEMzmO1I/A0MHJ/F4Kr8LUOchxeP
9NEzD+vtj387i28cF/ExRfJkQmKUySjH45//mHwgZjlcJtNkcx675ELEd7L7
8L1VK+2lO70ILaltMakMgosBB3G4HAliZ5ZMd8girce9TWZMNnLwOEb2UXlV
kSHZUAL+5HEhNLIAEzWCOS+BZ4T1cTabnEsSOoeDISK2N4UNno6awT4ZIwP+
DwmTPLxjxb1RqYvkdLIyFx8MwvGId0DwB5r9/OLr3w5I5HL4Cx7+a1qvUOp/
OHTTl/+YxTjSrThPFnCUruZDT+YuRB81SIp+D970NDmbTExg0WlcXKUVBwpr
OOqA0EPZL9lB/5eYqA9YqLOgpdCAsk+wZYQhSOOXYspZxryKfqFlgu0vj+vK
dAFIGRMMmYROWsVsX3ZS4DR2N8j0BSBZeujpqSbfjwwYwJb0xKPZ7f8vZYJN
wi8kWotYye+IgU01eKtH/nJiw0pdBHAWd5yaHpsCa4DORAJb2OXjOYOWpnA2
pli7UL1wsVvUWjs9sYiObBj6y7ReQGwPPfAweFJsImnBxsnMOxbdJTgpWFNN
Gd13cUrpGw7BjPUpRgOpNWk0jFhnzZ50rHEVTkXfYI1Ks4UH+DqSQiRGFmQL
C2sKltYpHTexGVf/SM0FmXd2XTZlLKvm0iEkuKTq7xo3cbn3SRC77uSj3s3S
O2c7nxWWK+dFV8porI6ZeOh1sU5oxYh6H1tdiqSCCKdjjIhgukzS/iwUYZke
3+i9j/oiufG2eGe1I2zCUDzCgMptWOOLWUmoZMCJg67CKRd4yBQXSQ8zTHpk
WHOcNhk2tJDaUc0yBPm8Tn0eQlOtwnZccCilL72th9GTLrYrjH64NuvWeXej
R6uZPoq3iG7/cIknxpdY+5C+QAdiYi3e0zc3Vdc2a87hXOwXKhhb22JjFWNH
Ljf2EtEbGYrUTkQ/xIPJflEqut/zfv9b2tueJvpjOIHib/e9a1/ilSMjD8ej
Vx5OD/x7eO8K/3roS3ojUKZkpP9V/KiL/VsxfZh+H1jEwTni7P8mf0mj2SLf
/a+9+443qOFqWEtxJBEixx/2btxb+m9EjGgnSkd/dTMp47/zSQHvu8MP/JjM
/bf9pWX//u2+H8fjHxRmDV/3HFmBUZrJPc3GTCk7Kr8XZ2C+sMGfSsmDoU0r
gPlRzGnahcsipbTcL9uPIl/O5+oPuSXCm+DoSdKSxmvUxs7TbL0xN0rT4AJL
KmbxjUDU1W6lVA+RH0ekpoWUuTQf9J45wlNgfJzsGSaIFkFLvqprjf9eWUjE
OF5/IWa6+c4dDuA5uIbTnH3lq5Bd2gpyWYIrVxzkxIfmcaN54k2KPD7gTBI3
IR5ObFv69bhYRAWV1aXCd4hUDg04AhqVXRKOJcX1Kgk9cZZCKdmLllyZJFTa
ZUgupZE4ImwZWoDQ/Ri+yEhOJG6/ejv36NHo0XvoUfKcneHeyKlscvci/nrv
Iv4aHs0IFOCh0yrZ/xEfjQXt0ZV4QEpWTg9d/DGR6UFaOFk4FaXKYqaBDHZ1
5ru87Ha46b10zBmuLUI5XCATClV7imPJQAir4eD3MrSI43uo4Six3U0o+mid
VAnxZmGB2nMqJlLSZrkhrExvk7uDz0lP1lkCnTSBY/ZdQ5MMkAbpz9PFW79U
UdfR55dS2FiDPYSGWKZ9rCiQB3wnvpi0QR+GY46O0VZpJE/eKl7qPltv0kO3
6a5/UXr40XqQ/e2AzHLfv4i+P1p8VyoO/dX9aF5IklZYSNET4g+JKPPPmDFi
hXz80bwpf3MHh8+X8oE7jif4G17Qc/4NbwRM+A3vhOOWf3u32Ry5epfTLpVv
9hrZ8dcvuf41Swr79RO148dV3c6JuGs9C5PcY3QmSxYWipIXeJF6HJuNNOFm
fSV18ot2Iyr3qMSdhf/BUdKPimkIN5GKFtD1u6ut5nzvl5fFJnWsWJ+Y7540
o9XqRVlVxv3A0P0u51z5CetPPf2OHewcjGv90e+o6C19j3XQpGaclQ7lkMID
xQJGC+GIhxgGVBPVqCU6z1LpZ5LSYVWelf5auUrNBWAjXTJ1Jh7OJcwfgCWR
VcYhrAUMk10oA3gjdRH36LbOWw0sIHDuQOdv2rdSq8JaeohZZX8Tz5PqmTqD
1OsS1EkcyuK2RXY70oY49b7ZWUHRw1E0ciKzIpQd5WSiXViHS2txitYbsw6y
OA9Gq+cafo/lSpPfFkU9tj4dJytSmZejC2Ufmav123Visfgg6n1Qv/x1mt3c
KWrwv3fFExePv4pJs0yqH7KkIT+CkEc84Dn344f4wJRMvYFTjRlWAiE6fz0P
EKdXH1I+s1JOfAc8x/UzrP9hYq86nDXC1o+0tHlI1Ajmntj3Jmmqq7mK3VrI
3MG6/yi1Kj+k8dJCdAjc/JMKC3aVUNiCAxHycvqx7n9W+lJi7kOL6B4dcbhE
9n5ZYUTgcSMCdxcpOAo5M9CyLCYEf0uc0jGnkb7Kw53OtHaqkG7xoXPCUtUv
tr1mEu6VouNksXygRTYQe3adNuyraIPaHvMnEiSr+BJ/ySamYbfxoyF7I+Ba
tSUvuvbK6hsdnV+8Olbj+aavuO4nMgT2qn3GturS42+V1Lo4klwHBGpxhPur
85tPJu7i7FI/vwg1qL5/ER/5mDCk4Ij71Dw/76rlVdZfwMVspqMQ6riptxps
qrkSEqBwFBWm41jMKQOMSxhzcGzHRDxOwe81lKDyw2oUSdBzSOKpDjA6xjXj
b1peKVgf7jQFIgB71NCFBPCLrNTeKOOcC4qE4D4GYZo2quk+SuS7vGok0mUq
5Rcm5cRyOi5mrsc8vf3iOKHpcDlKmVqXS5+42oguPvyj/XvIFDz7GD/Jr/k3
7l3Qwd4JnU4/xk9G3dNv/q55dbQxl7jvY/H3zvkuYK7sNfsYP4W9Jt/84/dK
//43//fR3vfhm/89nrYYj7433f4XDjOD3uRr2Pv2vi94HSIZPEwWsvft+IuH
+iGA4R3I1P5BMx1Lvk0fw3/o4zt9nwjg/vtM/bL342P8/tm5vg+6uf8+aGb2
fvIY/QeUVN//9PHT2e/33h+Pyo89efIu/ZvfV+nq4ej98ajpYw9/TfRKHjkq
jxObZXE0P46plGl9NPppcSxhhZzRQASwWnKsUUzXlqPXdKpRvhLPqmHGy23H
cTPS9WdvlQcyT+1fHrGdEDQT9IhbjkPE72CyLOZltUJFPge/fQ+oQG6H2JOV
atQiXtvejDOo1eqSGiQhcizpGA3lkb1f2ioiKQDNodsENkuUd1a//QD3Cy0w
1HeaJjUR79McSoymWkM4mMCVzIKUKSYu3fj8+OTA4R04EqRcamHTruDbSDjh
LJte+gsKHm1CQT0UaPCdv2d4tfWmPfZYHQ+254U1QFCwMDRiTRRmu1xDTb9x
KyQ+zIrvhG9KHuw1xy7mvDpviJQVHuDClYq0GQYe0u8EjItjCwoWvQHDOU7y
hBbJuQJTyxXAtfAhRkUSeyXR0mQlgyS3YjL1Lgau0fdSc5MmEMHSbFNfdAzg
CUKhev4DQ15w1xntu+mcFM1glTzpCSflC1EWKTY0TyulTKRMsXaoZLEm1qG1
Qgk8KL2y5foBdDBWDT4ZFIqMti0KyaKdEzkpqV8LMdz3WRHC2Fs6PMcZC9sG
otvR+Yvv++OJo/dC7rOAbNuEJS1Da2kekXtKT5K+92bgmnst/agODixj29G9
y2+5Gkb0gVAsUcN0F9doTFloCbg2tgh0cSeiPshpieidgJ8LvoXIaF4TZ5Kq
+ulQQWNXcqHPdNdlmMiKqs/gp2u5DS/iKjKjghx8kqQ4FRlWC1jm1fZ66QSv
vYvS+j4J/dOU9VLbynMsbdhUEsaL+skuFK/UYjR8opVGxUtnp0pK4NglnXAM
s62WaUzDtdfSap3qEJKui2wQ2diBx4VIKRMF7zZRqhFxlC1MarslHcuTesWK
1pxQ1ElPeCE7c9LbV5WUDBeCrzH0Cue2qyQKn8uo+h36odg+gMwCyOywtJO7
6WocPLHXuPtQDRGrc5z1SmeuonWMcNSmr8euqtoiJ6ArJ9JFosEqcsExYt7s
JhXW//zQ+LZqLU4kJrjQmH0ipRql/n+ZZMJKD83Oh37ZCnfxYIRCOUlNMQQf
zr0U0eeeptpka5AWn4xiWleAY9sPrlaCnwqrIAN9LSjEyf3lEwDZC8mQNIMF
VWYtb7XMv/ZSShbNemrVa2RsLO9RsayEuv3VYluX3d553bTVUmp9Wv/TuDVA
VvrycrDtTdVu+9Dm2UpbSvA691u74UL5knuhzQOtJo0ZsCJ1BN8su+hNS+rB
CyFXNIZ1M8JKUhA9cWp2MINJc7hUSE3t7zB8coATxA2F6QI0j5ugc7EYad8x
j2VSQovpqF2HtssSE5VBQU56LS7Dus4sIaNiKGI509pIfpmZ0C3qKqMqNLW1
YkuKTsXmG0jGDhfVFrRtjMZXyKrISUCoscRJfVw8TtxyBmllKlIvI+Q7HRnj
K5otl7+b2D3SSmlIoyL2GTrP39NQ2UohjxqdGV1n6TBUYjtM7hjzromf0OwV
cDutcUSw6b3WHFp01RyoIuwtKaeUcpFi2QI3iMiF/qgJXqUTs5ET4s8g8pdU
nl1v6AjtXJwQdGWDBzq6jRgo+2RsuzQFO12d8XQxirIA1ie5kErcmVRDQVnm
2IZ7PCtYUnKVJD5stn2UTw6NrtWERTpVB0DmPFJlprQUrIy1JzGDIY0LhWUg
MRQwbUrFTdfO/4PbYKi5MdQwEIeEhIqgW0KQSU29VNYlYcYIXJGRYvVqk4D4
bSt5YBISETnuULZk6Wrbc4v5iUPBXNFveOm7hEQtd7lUJBMLjWUxgNZVSluX
vVZ2cDaBYXFPNOLgvl4dawg97hyB8bbslv0Yc2Koet48FkgxKbhZjxP5vRPD
fTmkcm0Mv5R0Y6FpsHFC+Nk/SmTEVeqjHBEiaVFQRQ5InGvwnTFC5FbRIewr
nVrZIsNvzjyENFZpd2nuoYlsv7JSl1qQN4NvbciKYhMATnJ0U2zYQ7kAi9y9
4dDKngC72taTEVpOxrfm/I6bB4IRuJEtAFFM0oBW+sCN6luPyH/oSACldayT
F8FDA6Yz7bfc0jGtxabhcI3CX23EvavptLfCIwMNva1WpG9+2U6KN1tthHP2
8KGgRCjqOfdpNqe0wWNhxKoUs08CvdwHlsPP6Hx/OTlB+RZUKnEFB9Btyo1F
2MSCKuwfaXjyKev+/Y428BOJ2z6RQrm+D5en5sZP4kO27Uwbv+UofxSAhl4k
+X12zzMkQ0A5Le1RWFqq1l6g0vY36AxkPp5XUC+gyowDf2gaugrwtXsu0J0U
Dtsz/iexwXqhxt4bbUCsNQBRKpOIK7coYsnKiA1NBJkXrWhcMC8xF+Ss4Y8/
++Tx+/fSHOWbi8yrUff4H/LobR66CKSo8dpdHbeMjX3y8dvPeZQnn7z9nCsh
b7wW0ZsFWOHFvE07jyLhgoyysX30FkaTQs1SsWm6dBUrw5BWX1A6E0JCW8/r
OOC4/Lo12Y1V0kSoi27plNRKHXEERxFx5D4KUkrrrnJ0SZsPEV6sQG3W3LDx
V61EW7DFjyGbnJYCxYJMY2B6UvJySbpbIxlu8FbN2YbEbEYiDaW0FasZoStG
GlY6anJ3ioQe1oYVO8NytOD0dCq1n0gYukKrTrNGraRgH5urSDgJ3UgkemZh
lbFhdtM2clz7i8N02lQYxQxSRSounURhTSFmBVtbbCKXfySAW/lM0Mvl0p7n
olYgMUShx/yezWqrLRuCoH/0gayilHC74JAaMV99Tgc7hRQAQylqhFwRd629
kDAoc1kp0S4tE5uQP+uliYvUDaVW/JPU+YBuWs5Uq2RK5FBIjp+n65hEPppy
AheaLmix9vg6TI+m3KIw/ygdblwPlUt5cqMEHl9rqGqn62D3TLP1Y6XoMtRs
F2keBwBbj/phU5kMm+qtDwVrbkaA94YArrMwCtOh2zYIehQbmcWsaFEH7g++
isZ0OcY8cjs6gYmFsSNgooFiVl2B08OSTA7pOnmjLXz9jc/0E9R9RjEjM8gy
GNJ2u5Jts+BQI4n3YXOXdqEjzqXFYnpOrez8FXRqHD9qTwfjcGLTz7YYPea8
C/auS1G8WJoR1evS1rdblOySml3XbSXJNqEoSnSoM+cVYs2r547EAYsnozrg
FTeAJXnMLAFas5LlPxBuDgyz/US/PUqzodJGEgMT5Agca2JVpzViIX2Wc8O0
PimnfY0m4yDVsB+Q4rrVyuCz4ouqEeYMWaVdDV7dJlnxoUnx7eklKBwKNEmW
LTpEJH1ZLCI82FMxeYMtRimO7U5od91baR3tcnhXL2zCKxZDONeN9TSPju3t
lOt4ZO5/53IxOFpQpWdmP2qelEceBj0sotaGDporiBfT4kvWTDgzECE4PWeN
JtkMwVIgP4OuXfErsM4USFAa6+5KONb0CK3Q06VWE3qMZIq4wGaQokh1Wu3p
2kpYT9LUSlr/iMEv2P+0NyQkHvjpQv89Kxhq+n3xQ4XGmIgExeq5xHCsXtjn
F4pNZ1yDW/ZK02276HuUXZDqyS8RxG3ICb+dfcMw0sewhEmYxL45LkIlVybj
DE7ZqxQ/C/uc8eG8WuUYiyMxF93EWMRCmdZVOF5ds1xttsDNSZta4ohC68FQ
JefsZbLbOAYjTlaBxrAlxKYFMiR1aDSHmouC/4TLbaCT4k5qCB20yo9fxmou
0uOE897b1IfGBWr4V4LCsepskBcYj2x4MQpI1ebL7998awtBG89BenHSO8eT
2CovUhRFSWMGoe+WWq75qi9jl4GQ9zNGj5XgJN+GNEWbT/HL8cGwRGTZIiAl
BlG5MiHjJGlKVg0RUauG+RXdANHZQ7mOi8vvw+6ZTXRsURmdS4Qdc2h9927I
JUMp9PV1IQpDksGpC8tpVOgjKRGSM6ZFEktpUoFERQZ6pKGU0P13G80RLq3N
ulj/01bKoU26NSsakbPYFSyto7yVnj37nfhmo8Ulq8kvXGcxnqyOGj80tV/W
i4by2w1BWmpf5o3WJ1K/SIr3CHZhoBTBYucsXYZJs3tY9pXVjmVRt1Fvr3BT
u1YqNycwFxplTJlJRYx7Z9cBd1XBefNxn4Y6rKU0aQ25tG8CmEq0MOPtT2LA
mDzPbQ7YsxI727MgEE4tI87J0Y1MdooFaEeFPy7Ys0y704OR2Gm+LeZRiB0j
/E9ZLHk4bbnBAdJCkTNenXD4/CpmCIRxQox9KOsld8sCXtW5KyUwFqpYbrRG
2lUpbhgEhyqpTtrWKh0cSOO58Up5D1IlK4JPI5WsEGFGTbMP7Ce+ZBXvAsjl
ZvD6AnTo/mCVgnJ33ZN/ImLwT0bT01Yfr9TboWDjlanDtUWEqailESft7O4l
KMFZFyuocd8GrZ8oQpZtSrlYJcYb1dLT9kh6O/YovDKAlIa9TNWCqHqMxaq9
oUbJl+MTYAlTvHDK5wP9LdOi/FJ2Xwc5C4Nob+3gJW2ySuNJun4SRZ7XiJLl
N5MR2HGzpXA2LBRcj0+SAmxm6eOjHsRsnSgIKXZcxsT1fojXqNtwMgJLDk1S
xzqXeZkegxfkRe8YtZplbFqe1MGW6lmNfN9pn565TyujM5qw/+e2YjE3Jo3m
06P8Bzu5AF+U61lIZf6SUVIKWqOkvVgvtejNFfuJoxLKs73Y678Fj1STtvFj
8i6CWU5+JOiND+7sPCtOm1a32dcmi6SEKIQBjAAbGi/WBle5IlyoDHUy8vj9
i3MlWzw/+uWkEqR0Go5dKWFf7+UqseVKeCfW9lp7Sx64WOy/zWYIFS+S8wO/
ZTwHoefURmX7Qilqz362EPskkNYa+01oyoyueJFgZFJbCJSTFvQpJTjIMbBS
VhDErJYekeolFTcnSuUrxVQ8D8QJU8IrLYxayhAIvZSBk6RpEAe2VLKpMlBh
RZ25Fadjut6qM4d+XC5rP29/8sFY/VPSCS2BFAPma+8307LOvCipHbi3CLak
lOQkCVCEdqMyOIHb34ICi+rNMeWCBdhh345uMdFKaTRv+4KA4j7fFXn1SDGz
sk4nqrAo6nfr0ObGdFwZP9fGK2nurSWMd5lNeQkvVLsRA+MrkTLNQdt5dfUc
yNTYr5ALtssOZgYTZwrkhX8nRVYAMK+lE8oE0I9MDGq1h2Wmsx9YPEnKewar
HXMbZjbC7qL8EnGp7M3mIflfIxGAXcdzxIJIqiVSiUiYhKY5bgi1BSoysjAJ
dqFellw5Ju7LbSc5fmydY3l/IzlFIk1zPEan/E1DKDMjXYAjoWO5Zhsv4hem
EkUMI3OrZq0kwspUQm226LiX3AIBDrVfXknzTPca9kl4egVu35RbtmWdXW9L
sTn8Gc3Gim+8N4+HFb29sKKLX3YtyvIPxcvLr9y/0nfEUk3w6qr5NpBxMYVx
/c2kbHSKoBzlqEv5c+vdV1W99POOnQivAaGGHmjXvRWpeU1zlb4ufvD1z7Xp
GRXCIvxyLm77GMyCKwH2T/gQyUF2Pdi0fN1uINt+QfNu4Rd5+vjJH/BFsjOM
pHlSYvEUiZhdC4QfdGe8kGXdpQVkLAtQuEr6Blcyn7bC08Pfi0p7uUUOftlI
M08LdEFy7FckW/xMn54+fvrYXaGXUVFedV4icpp2Vnzy6acfP31SvI5tRsWt
nvSqUg3hdSCZSxd6Wh29Pn39SqtB6WIuSJToESE+oDkCUtZK3D0e5eVyaz1p
0IsUHbEkH/5V07TaJVQWzngBuzQW+eTZ7PHTTz7V22JRKKOKSnRkbdd7dX0g
6xqHC3xGXe3iFcyovcLUfCSFVdmywhwJeXuu3bGSAihSVo8NstK0Ofj7YJEb
hk1/8ujRFV2u7XxGxPfRulxXUzppBGM8WnblakCe1XoNHzaRgGGqTfweVbq4
/ws9LUaEJfAAAA==

-->

</rfc>

