<?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.3.13 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-per-app-networking-considerations-00" category="info" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.2.1 -->
  <front>
    <title abbrev="Per App Considerations">Per-Application Networking Considerations</title>
    <seriesInfo name="Internet-Draft" value="draft-per-app-networking-considerations-00"/>
    <author initials="L." surname="Colitti" fullname="Lorenzo Colitti">
      <organization>Google</organization>
      <address>
        <postal>
          <street>Shibuya 3-21-3</street>
          <city>Shibuya, Tokyo  150-0002</city>
          <country>Japan</country>
        </postal>
        <email>lorenzo@google.com</email>
      </address>
    </author>
    <author initials="T." surname="Pauly" fullname="Tommy Pauly">
      <organization>Apple Inc.</organization>
      <address>
        <postal>
          <street>One Apple Park Way</street>
          <city>Cupertino, California 95014</city>
          <country>United States of America</country>
        </postal>
        <email>tpauly@apple.com</email>
      </address>
    </author>
    <date year="2020" month="November" day="15"/>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>This document describes considerations for and implications of using application identifiers as a method of differentiating traffic on networks. Specifically, it discusses privacy considerations, possible mitigations, and considerations for user experience and API design.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Source for this draft and an issue tracker can be found at
  <eref target="https://github.com/tfpauly/per-app-networking-considerations"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>There are a number of use cases where network operators, or applications, might desire for application traffic to be treated differently by the network. Some examples are:</t>
      <ul spacing="normal">
        <li>Network-specific services. Applications might want to access local resources on a network that does not otherwise provide Internet access (for example, an entertainment system on an airplane).</li>
        <li>Per-application private networks. Certain applications, such as enterprise applications, might want to connect directly to the enterprise network in a secure fashion without using a device-wide VPN.</li>
        <li>Mobile network services. In mobile networks, applications like voice over LTE, IMS and RCS often use a different virtual network than general Internet traffic.</li>
        <li>Applications with specific performance requirements. Certain applications would benefit from particular scheduling or QoS policies - for example applications requiring low latency such as voice might be scheduled and queued differently from latency-insensitive traffic.</li>
        <li>Local breakout. In a mobile networks, applications might want to access resources through a different network interface (e.g., one that uses IPv6 addresses that are local to a specific area, and do not have a wide mobility).</li>
        <li>Zero-rating traffic. As allowed by regulators, certain classes of traffic (e.g., messaging or streaming video) might be exempt from metering on networks that are otherwise metered.</li>
      </ul>
      <t>In existing networks, this is sometimes implemented by the network using deep packet inspection (e.g., flow tracking coupled with inspection of the SNI handshake). This is complex, implicates public policy concerns, and generally conflicts with the recommendations in <xref target="RFC7258" format="default"/>. The move towards encrypted protocols such as <xref target="RFC8484" format="default"/> and <xref target="I-D.ietf-tls-esni" format="default"/> will make this more difficult for some operators. Thus, if an application is to receive different treatment, the host or the application itself should be involved in requesting specific network treatment. This document explores the implications.</t>
      <t>In this document, the term "application" refers to an application as understood by the user of the device.</t>
      <section anchor="conventions" numbered="true" toc="default">
        <name>Conventions and Definitions</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/>
when, and only when, they appear in all capitals, as shown here.</t>
      </section>
    </section>
    <section anchor="requesting-differential-treatment" numbered="true" toc="default">
      <name>Requesting differential treatment</name>
      <t>There are already mechanisms for applications to request and obtain particular treatment by the network, or to communicate application identity to the network in order to obtain particular treatment. These include:</t>
      <ul spacing="normal">
        <li>Diffserv</li>
        <li>APN6</li>
        <li>Network tokens</li>
        <li>Slicing in 3GPP 5G networks</li>
        <li>Explicit application selection of a given Provisioning Domain (PvD) <xref target="RFC8801" format="default"/></li>
      </ul>
    </section>
    <section anchor="open-internet-implications" numbered="true" toc="default">
      <name>Open Internet implications</name>
      <t>In certain regulatory regions, networks that provide general Internet access may not be permitted to discriminate between traffic sent to or from different lawful applications or websites, or such discrimination may be prohibited if commercially based. In a situation where the network operator has influence on the implementation of the user host (e.g., mobile networks where the handset is sold by the carrier), the device may be able to implement network policies directly, and thus may be impacted by neutrality considerations.</t>
      <t>Neutrality concerns can be addressed by providing user control over assignment of particular applications to the particular network resources available to that user. Further, network neutrality implications may be reduced or avoided in some jurisdictions if the differential treatment occurs between different classes of traffic with different network requirements (e.g., bandwidth-intensive traffic vs. low-latency traffic) as opposed to between different applications with similar network requirements, and thus, by ensuring that the mechanism used to communicate requests to the network only specifies traffic classes and not individual applications.</t>
    </section>
    <section anchor="privacy-implications" numbered="true" toc="default">
      <name>Privacy implications</name>
      <t>IETF guidance to avoid pervasive monitoring <xref target="RFC7258" format="default"/> is for network protocols to expose as little information as possible. Some of the proposed technologies for application signalling rely on the application exposing its identity to the network so that the network can then implement appropriate policies. This may provide the network with much more information than is needed to implement the desired behaviour. Information about which users are using specific applications, or visiting certain destinations, and when, can be highly privacy-sensitive.</t>
      <t>Note that application identity can be exposed to the network even in the absence of explicit signalling. For example, if the host were to implement a network-set policy that requires that traffic from application X be sent on a different network path than all other traffic, the identity of application X would be exposed to the network as soon as it sends traffic.</t>
      <t>Privacy concerns may also be reduced or avoided if the mechanism to request a different class of service only specifies the class of service (e.g., "low latency" or "streaming video") instead of the application originating the traffic.</t>
      <t>In a situation where the network operator has influence over the implementation of the user host, the operator can still impose policies on what requests are possible - for example, the operator might choose to limit access to specialized services such as carrier messaging only to carrier applications. It is possible for such policies to preserve privacy if the policies specify general categories of traffic as opposed to specifying applications.</t>
    </section>
    <section anchor="mitigating-implications-via-traffic-categories" numbered="true" toc="default">
      <name>Mitigating implications via traffic categories</name>
      <t>Many of these implications can be mitigated if the mechanism does not request different treatment of a service for a particular application, but instead specifies a general category of traffic, especially one that is defined based on traffic properties rather than commercial agreements.</t>
      <t>Categories of traffic need to be sufficiently broad to not identify individual applications, and should be general enough that details about a user cannot be inferred merely by use of the category.</t>
      <t>Consider the example a network that wants to provide differentiated service for a role-playing game application that can take advantage of a low-latency path. Several levels of categories could be defined. The following list shows some examples, in order of decreasing specificity:</t>
      <ol spacing="normal" type="1"><li>Role-playing game</li>
        <li>Game</li>
        <li>Real-time/low-latency</li>
      </ol>
      <t>The first category would not be an appropriate choice due to the privacy implications of identifying what kind of game a user plays. The second category is preferable, but the third is best since it defines a way to manage the network traffic without identifying anything about the content of the application.</t>
      <t>Some use cases for traffic differentiation might need other kinds of categories. For example, operators might wish to zero-rate applications using categories based on payment tiers and rate-limiting.</t>
    </section>
    <section anchor="user-experience-considerations" numbered="true" toc="default">
      <name>User experience considerations</name>
      <t>Privacy and neutrality concerns can be mitigated if the host's user is informed that particular applications are seeking or designated for particular treatment and consents to it. In order for consent to be meaningful, the user should be presented with a message that they understand. It may be difficult to balance the goal of providing complete and accurate information with the goal of ensuring that the user understands the implications.</t>
    </section>
    <section anchor="api-considerations" numbered="true" toc="default">
      <name>API considerations</name>
      <t>It is desirable to provide an API layer that is not tied to specific network technologies (e.g., URSP, VPN, etc.). Having applications select a specific Provisioning Domain (PvD) could provide a useful layer of abstraction, as described in <xref target="I-D.ietf-taps-interface" format="default"/>.</t>
      <t>Any API should not involve revealing an application or user identity to the network via metadata without network authentication. Instead, the API should allow a given setting to be conditional on the identity of the network. For example, an application should express "use the zero-rated service for my app when on a particular carrier network", instead of blindly saying "this is my application identifier".</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <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="RFC8484" target="https://www.rfc-editor.org/info/rfc8484">
          <front>
            <title>DNS Queries over HTTPS (DoH)</title>
            <author initials="P." surname="Hoffman" fullname="P. Hoffman">
              <organization/>
            </author>
            <author initials="P." surname="McManus" fullname="P. McManus">
              <organization/>
            </author>
            <date year="2018" month="October"/>
            <abstract>
              <t>This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS.  Each DNS query-response pair is mapped into an HTTP exchange.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8484"/>
          <seriesInfo name="DOI" value="10.17487/RFC8484"/>
        </reference>
        <reference anchor="I-D.ietf-tls-esni" target="http://www.ietf.org/internet-drafts/draft-ietf-tls-esni-08.txt">
          <front>
            <title>TLS Encrypted Client Hello</title>
            <author initials="E" surname="Rescorla" fullname="Eric Rescorla">
              <organization/>
            </author>
            <author initials="K" surname="Oku" fullname="Kazuho Oku">
              <organization/>
            </author>
            <author initials="N" surname="Sullivan" fullname="Nick Sullivan">
              <organization/>
            </author>
            <author initials="C" surname="Wood" fullname="Christopher Wood">
              <organization/>
            </author>
            <date month="October" day="16" year="2020"/>
            <abstract>
              <t>This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-08"/>
        </reference>
        <reference anchor="RFC8801" target="https://www.rfc-editor.org/info/rfc8801">
          <front>
            <title>Discovering Provisioning Domain Names and Data</title>
            <author initials="P." surname="Pfister" fullname="P. Pfister">
              <organization/>
            </author>
            <author initials="É." surname="Vyncke" fullname="É. Vyncke">
              <organization/>
            </author>
            <author initials="T." surname="Pauly" fullname="T. Pauly">
              <organization/>
            </author>
            <author initials="D." surname="Schinazi" fullname="D. Schinazi">
              <organization/>
            </author>
            <author initials="W." surname="Shao" fullname="W. Shao">
              <organization/>
            </author>
            <date year="2020" month="July"/>
            <abstract>
              <t>Provisioning Domains (PvDs) are defined as consistent sets of network configuration information. PvDs allows hosts to manage connections to multiple networks and interfaces simultaneously, such as when a home router provides connectivity through both a broadband and cellular network provider.</t>
              <t>This document defines a mechanism for explicitly identifying PvDs through a Router Advertisement (RA) option. This RA option announces a PvD identifier, which hosts can compare to differentiate between PvDs. The option can directly carry some information about a PvD and can optionally point to PvD Additional Information that can be retrieved using HTTP over TLS.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8801"/>
          <seriesInfo name="DOI" value="10.17487/RFC8801"/>
        </reference>
        <reference anchor="I-D.ietf-taps-interface" target="http://www.ietf.org/internet-drafts/draft-ietf-taps-interface-10.txt">
          <front>
            <title>An Abstract Application Layer Interface to Transport Services</title>
            <author initials="B" surname="Trammell" fullname="Brian Trammell">
              <organization/>
            </author>
            <author initials="M" surname="Welzl" fullname="Michael Welzl">
              <organization/>
            </author>
            <author initials="T" surname="Enghardt" fullname="Theresa Enghardt">
              <organization/>
            </author>
            <author initials="G" surname="Fairhurst" fullname="Gorry Fairhurst">
              <organization/>
            </author>
            <author initials="M" surname="Kuehlewind" fullname="Mirja Kuehlewind">
              <organization/>
            </author>
            <author initials="C" surname="Perkins" fullname="Colin Perkins">
              <organization/>
            </author>
            <author initials="P" surname="Tiesel" fullname="Philipp Tiesel">
              <organization/>
            </author>
            <author initials="C" surname="Wood" fullname="Christopher Wood">
              <organization/>
            </author>
            <author initials="T" surname="Pauly" fullname="Tommy Pauly">
              <organization/>
            </author>
            <date month="November" day="2" year="2020"/>
            <abstract>
              <t>This document describes an abstract application programming interface, API, to the transport layer, following the Transport Services Architecture.  It supports the asynchronous, atomic transmission of messages over transport protocols and network paths dynamically selected at runtime.  It is intended to replace the traditional BSD sockets API as the common interface to the transport layer, in an environment where endpoints could select from multiple interfaces and potential transport protocols.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-taps-interface-10"/>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgments" toc="default">
      <name>Acknowledgments</name>
      <t>Thanks to Adi Masputra and Elliot Briggs for their inputs to this discussion.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAFf5sV8AA51abW8ctxH+fr+Ctb9YwK0qOXbiCCgaRbIdFXq5WHLfgqDg
7fLuWO0uL0vunS+GgPyNAu2fyy/pM0Mul7s6tUUDB5b2hRzOPPPMM7POsmzi
tCvViZipJjtdr0udS6dNLa6V25rmXtdLcWZqqwvV8A07kfN5ozb8hsAb49uF
yWtZYcWikQuXrbGuXK+zOq6X5YMXsqOjCfZUS9PsToSuF2Yy0evmRLimte7l
0dHXRy8n92qHt4sTcVE71WCt7JxWn0ysk3XxN1maGjvulJ2s9Yn4wZl8Kqxp
XKMWFj/tKvrhx8lEtm5lmpOJyCYC/+nanojLQxyh1M5pvuaNvzSNqn82gzum
WZ6I98YsS8W/Wyyv3Im4Xel5u5Pii+zlcfYF38q128UbU3Fn7ndGiOPXRzgt
jsOPmLZ2dOQ/yLWs+ZKqpC5PROn3/mbJWx3mphrYe3coZrItd4m1d6aqdslV
tpSiqeCw/HBg7U2twq2ZbO7Fn+QusfisRbycrs1UnMlSL0xTaym+fn10/Gpo
9MdaO1WIW4fIWWEW4rRSDbCTnsOtyaBvJG3Gp5hkWSbkHJbIHLG7W2krAJe2
UrUThbJ5o+dYbYgPASMEgix0FdHJO7aWwCkTzOKl2umFVo0VEn9EpRDugh4u
9GKhGrqNR/EaTFgsdC7wVkCmPRS3a5Xj9VyW5W4qNGzSNm+thU3rRm9kvhvZ
NhVrY62ew5mVdnrZXSVz95yitUgZ9Qku1qrOFT92Orugo+tlfej9U+miAMAm
zwnrjSnanM/2+blOfn0g7+E8QtL/om6rOZZmpyiRS7J4y/fD4YRZkyWmgXHk
zt5puFDp5Yr9r/HCYng7OsoZMVf4TUmKe3RnuRPznXCruBO8aCqFU0qEC2bA
wBMcrOOTzAYfC/hio3MFtye0Y4MxWwlEYEuZ4wmLjEBMRKOsaZuc8FbTocPR
3ErCeoPLtXHCwJZmq+GGdWM2CECkjG6xF3TEYB+FSih6wEldMw7tzjpV8Rb4
o5t1KWt1QMFhjkx9w6BwKkHQmV9o5GDb5isCJG+El2Dcvgh0hwZyapUT+hr8
BQ/jGnk4eb07O20FT+YtRU7aFVm11QB967r8QGDJz9mWfPHH2TWf5MrMddkv
08fiohbV4B6hOY1Pqe+V2Bg8LcwGmLu8ezsVF1e3DOYPZ7cAoVM141D2MBEb
3bgWMUyCVoulqoHKso9QABubOEAFnUlE6ADLiGElKYca9VMLP1HonvC/2Jq2
LIDeWi2Q04vGVGItwXJ5W8pG2HylirYkXwEX35tb5DTe1cBTJhKoDNf029JL
pdmKEiiowQ5doL1/fFSRNWEL5A056adWtaMUYpvCIhlIXoE6nN6ogUMuOQlQ
e+U9wsuhkv8lWHuTqU8jt2pMu1wNAtUjCzFZSBzjhTpcHoI2UDc41Vpil4vZ
5kshiwKLWV4JN4iLfKbSZn24cF16TiwM5+hKbggdjEg+AGqPz7C/qsZkzYCi
wQ9gkRJuhtPANY1aIm6eyvIQ7ryUbAYIsOOrYHUF++QyBJdKoKzoFyIGc9BH
SH1S1TpgA0VDcWST2tAfsOcXfk4VsBuRUJ+0Zav7SDgqb/hjwYdOwxCuYIxU
f5KENUOyFkqtgc38HrkAGMCBzDPhLAuCGtVOVmUoxWuCFKdG8jD5AAvfXl/A
z3VhV/Ie9CXugjWow3jt0zSWUypu7byktCLcc4mDX7syFnK05OsLPOBCNtIm
4CcoD1UXAW8IxefPv//w7uyrl6/fPDzQrhRhArLZyqYgCsyb3ZocAHqGTDOl
jVnjX33z6s2rhwfeGxcusvNDrdwic6XNlK01bm11WYoKx/IuriCXGMCU0I5T
llzelzwyo8Vx9IIpPRUMlqCKUyhKtj4JuMxRoKZ8zJWxjvBDPw9ed1aVC2FX
gWBw/o0pNzgcHEEMoTwmYiZE9uvWD3GJIgjigNSf5a1SweNR5tKHvW3AYCV+
/eWfiV2//vIv7L4gFUSJODwy/NzWkCXWGRNRyMIkAMeXC+z3/DlJ+w1pJoot
BeQcDArhx79/fp73d70eEZDpgnS6Fc+uPt7ePZv6v8X1Df/84e33Hy8+vD2n
n2+/O728jD90T9x+d/PxEvcn4af+zbObq6u31+f+ZVwVo0tXp3955hH77GZ2
d3FzfXr5jMJALptE/1IGeyWjfTFVBEX4pFOfHLpvz2bi+BXg9xvg8eXx8dcA
nf/lzfFXAOcE2qr2m5kameF/hfN25GqFokIlCCDN5Vo7WVIqWYLJthakysi5
4kOPj0Sclj02BhKvxNViB87JkdTaVnYs1AKSeU1v2ZypMal0ceUR+bAkZN1R
VW3NnLBHVruoQxLxgVgrfvc/7MYsYMnjedkWXg2e48QkOqjOz66/7PUh1rpH
9cOFWyrCcA5W/eL9bCZev4/cirtvP5F9KOepocjGngSlWCKpazEjGWhxkRY7
NxWZ+WK2OT/o+ObN0TFCiojcrPF41CJp9nHydcUmFiCuRV7ADetEpzwf6ZtQ
gSu54zoIGIKj0DkQCOFEajcajQJFEZhjSaV6AW6Vr+KIFZepnq1KuV205RAM
eGqr5lARyit+5thkfXISmTFnnYw+lds5MCQTepNrpvw5OokiKA2s1fr3fGeR
IqGjWlQcKgKLsuX+htqHwGNc9mRaoJhzmFm7Uj2UMsk2XMcoJFRMy8hauWzQ
SDUH04S3ukNJ6sngrbh3tDWqu05e+0R2KBHdy3gJDaov0rVqEQFSKKOODkl8
PbjHRRNG1bx/kEa8hscD4Y8PjWfRyZVeP0O4oPdjC+GYJH/GuU1nTG53x+nV
nNyg6+7O3Sm15lC8axvSLBGk6ZEGPXU4PTRNm8Nw4hcI2cJzIpfUv7foPgqd
h2ofCsZe9hImR1diI4x7uO4RaywoHmvQVNt3KJkjWBCObpURgyMgvUoWG5R6
aKSsk+Ph+gGxr1mjVfdp9tgk+bjXQJoM3dyb0gNmStGFES3rRfY5eSSyNEWg
GFNrIGk7plMuJUEqkAIIh+rcRXsSaei60EATNVOp2VxTZmFKMeKut3fvxLLV
BTdMJAkorEQ9G8n+q0COyF46QyrfKN+oysTMiYoNa0CpGOrxqCN0rlQ8uUNP
1omMbjAS5gEh6bFECANcVJvSLOmo45kDZQT4h+xpFJwSeCR9hLfn8gBHPlWg
rOlj0l2j/MTvdcIMWBdmNZqC07FDEGaUEh2bp6swRiriVFaf6dm5s8WrtVKF
D36/k+cpmrOQXEQbpJG7xK+J6+bUu29XGmtT/vIEJbQHfUc1mB7Ae1ThWEp0
RapgaZHOo7xICfS0QuNT7rqpVhYbTiI140Kjt1cDhAV8+IuxxxVVXB3CNbe+
CixY1nK17iMLXkrHMIFLuB5sVTPi7jjsyagMhD6FbQx5GQpvlzNcIFPz/8xt
ONNSvbfdXUtuaaTXbdzkdav58hIdQNJisHI3XnjKJyT9jE8K8gC6JZv09bN+
sOgLCEEOktE8RcWLEcWksm/MsmRsmO08ohcqoONnAseinUimGtROwABcHPXP
uHFAnaeDNO0SPHUNGGXJGGRuTIcZ/7egoIr5P0gKH7K4CGEW6YDA4j1iragB
ePMAI+ZkSrY40x3Mf0Zr+tFBvjK0HmJQomBEgYff2dMosj8jZt14LXa6Qbmk
04naz/m6OwNqFxesfaJdi07QxXPgTfQytI+Ko+qAlPiMj/0uqtLw0UUPS/Gw
VIZ3RoN2X2yuwsSbSDiVERst++IV95hMrmS9C5Gyw+a2I5UwQ9+H8jjf7bC+
p1n3qr/DMheVJwQV6nbrInT7pJBj5+wS10yFCkHlkhRIkhpy6oqJ0Ukti2Rm
TmWFPqdgZYCGKYUYppfYQi4bFWaXk8nZ3oBQHQk9q23pig5j98ZIvsGiwH/5
2D2lDnwJ6AcV3TFVzQNAP0JXqBwo7r4CyaBVZR06FWShaqhwwXblx/405A2p
1/mLjhFksp9Zd8PT4bieRpIBtb64pt9n+owJQYRYVtm6lIzDpayGNMMLclmn
kZAsNlhbLpVHQyoHieMhR1Cj6Ogl/i7Z00ki5J2DQkz9BGthaPzIw14N6FEj
78d68TPHtG+G6WOTyoHJQcmmr2uTyfGh+DA+y+TloXhPf3+Bm0qWGc0Kf5vY
7UcrC91Y18PSF50QGj/iiRoGpES+K1oV+4Y9upAM7WBDtjAP3uuaqdw72UOA
jLXeEVahTBW9FURKPGmitsMnFRP9SjcF3ZxTpsIPsIa+prFPKcu2ksmukjUF
KiX+tCMgGKYWgj+wMv3ACGXYGWoC3J7qAyCy8Ow/iBGWuuUHnwOpFWY251Tz
tZ8cMQLHSLHE8WI3Zdd2RYf6OYywRx8MvIJLoBbZYi13Xhz675bwL72dcUEh
oURc+3H05XDYivYqgpuEp7vSRwRLxfLXX/5hfaS1DUqWGIcHGU+0o1QlrVL3
Ya7uv1/yuuTkvSOn7pOoComv/RcMnzP0VrgZqK5SkgY2i7ac9qW95y8udjxH
ZyUuQyVVUe/vuikn9uX6GZrbfk5M+8jSt0TYYGnACdSBx17dT8qd/0wrqZul
oKZSP87Bu5cft4Jsd2/K3sHuD36I7n48Ec/Fi7ub85sTP+l16pMHpe2GlhWZ
p4oDwgR9OR7j4CIUJLQY3SSgY1gggN5AMvs6xE8SgQB3Sa1Pp9Rpjxak4ccP
t7MpfUZENXT54cGh+A5dzEgehEFc+g3o6Smcp9xoJXmMplneTuLw8O8FuGyP
J7WDLwRybbP42erh4QnPyqJgx8KHpxAk5JOAK99d8wQfMmMDLvasMxK1IVee
6DlJ/VSopIV0MrJYbAVaaj1dR1FIAFYgHuKJJfy5K04w0fN4Dc0YIAbmETxB
rn7Umww+xb8bfekeNNl+K5AKDapI3hNV0uuRwYZ1uOLpNveRvotK8ryTrWFn
dAbTtDOYw5MFtR++7GGv7uOYX3TPv+DAEuEfRMxlfs94z+9rsy1VsfQDoc/P
5fDKw+Tzif+XEKr43bMFmij1jD9MyPqeM+i00OJK2jXxI2f1W7SiCPq3aFSW
oUCslKbxPZ4JAxrKJ//PQLiq/Bv1nhM3MyUAAA==

-->

</rfc>
