<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.22 1.7.1 (Ruby 3.1.4) 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-iab-m-ten-workshop-02" category="info" consensus="true" submissionType="IAB" tocInclude="true" sortRefs="true" symRefs="true" version="3"> version="3" number="9490">
  <!-- xml2rfc v2v3 conversion 3.18.0 3.18.1 -->

<front>
    <title abbrev="M-TEN workshop report">Report Workshop Report">Report from the IAB workshop Workshop on Management Techniques in Encrypted Networks (M-TEN)</title>
    <seriesInfo name="Internet-Draft" value="draft-iab-m-ten-workshop-02"/> name="RFC" value="9490"/>
    <author initials="M." surname="Knodel" fullname="Mallory Knodel">
      <organization>Center for Democracy &amp; Technology</organization>
      <address>
        <email>mknodel@cdt.org</email>
      </address>
    </author>
    <author initials="W." surname="Hardaker" fullname="Wes Hardaker">
      <organization/>
      <address>
        <email>ietf@hardakers.net</email>
      </address>
    </author>
    <author initials="T." surname="Pauly" fullname="Tommy Pauly">
      <organization/>
      <address>
        <email>tpauly@apple.com</email>
      </address>
    </author>
    <date year="2023" month="August" day="14"/> year="2024" month="January"/>
    <keyword>encryption</keyword>
    <keyword>network management</keyword>

    <abstract>
<t>The “Management "Management Techniques in Encrypted Networks (M-TEN)” (M-TEN)" workshop was convened by the Internet Architecture Board (IAB) from 17 October 2022 to 19 October 2022 as a three-day online meeting. The workshop was organized in three parts to discuss ways to improve network management techniques in support of even broader adoption of encryption on the Internet. This report summarizes the workshop's discussion and identifies topics that warrant future work and consideration.</t>
      <t>Note that this document is a report on the proceedings of the
workshop. The views and positions documented in this report are those
of the expressed during the workshop by participants and do not
necessarily reflect IAB views and positions.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://intarchboard.github.io/m-ten-workshop-public/draft-iab-m-ten-workshop.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-iab-m-ten-workshop/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/intarchboard/m-ten-workshop-public"/>.</t>
    </note>
  </front>
  <middle>

<section anchor="intro">
      <name>Introduction</name>
      <t>The Internet Architecture Board (IAB) holds occasional workshops
      designed to consider long-term issues and strategies for the
      Internet, and to suggest future directions for the Internet
      architecture.  This long-term planning function of the IAB is
      complementary to the ongoing engineering efforts performed by working
      groups of the Internet Engineering Task Force (IETF).</t>
      <t>User privacy and security are constantly being improved by increasingly strong and more widely deployed encryption. This workshop aims to discuss ways to improve network management techniques in support of even broader adoption of encryption on the Internet.</t>
      <t>Network management techniques need to evolve to work effectively and reliably in the presence of ubiquitous traffic encryption and to support techniques that enhance user privacy. In an all-encrypted network, it is not viable to rely on unencrypted metadata for network monitoring and security functions, troubleshooting devices, and passive traffic measurements. New approaches are needed to track network behaviors, e.g., by directly cooperating with endpoints and applications, increasing use of in-band telemetry, increasing use of active measurement approaches, and privacy-preserving inference techniques.</t>
      <t>The aim of this IAB online workshop from October 17-19, 2022, has been to provide a platform to explore the interaction between network management and traffic encryption and to initiate new work on collaborative approaches that promote security and user privacy while supporting operational requirements. As such such, the workshop addressed the following questions:</t>
      <ul spacing="normal">
        <li>What
        <li>
          <t>What are actionable network management requirements?</li>
        <li>Who requirements?</t>
        </li>
        <li>
          <t>Who is willing to work on collaborative solutions?</li>
        <li>What solutions?</t>
        </li>
        <li>
          <t>What are the starting points for collaborative solutions?</li> solutions?</t>
        </li>
      </ul>
      <section anchor="about-this-workshop-report-content">
        <name>About this workshop report content</name> This Workshop Report Content</name>
        <t>This document is a report on the proceedings of the workshop. The
views and positions documented in this report are those of the
expressed during the
workshop by participants and do not necessarily
reflect IAB views and positions.</t>
        <t>Furthermore, the content of the report comes from presentations given
by workshop participants and notes taken during the discussions,
without interpretation or validation.  Thus, the content of this
report follows the flow and dialog of the workshop but does not
attempt to capture a consensus.</t>
      </section>
    </section>
    <section anchor="workshop-scope-and-discussion">
      <name>Workshop Scope and Discussion</name>
      <t>The workshop was organized held across three days with all-group discussion slots, one per day. The following topic areas were identified identified, and the program committee organized paper submissions into three main themes for each of the three discussion slots. During each discussion, those papers were presented sequentially with open discussion held at the end of each day.</t>
      <section anchor="day1">
        <name>“Where we are”
        <name>"Where We Are" - Requirements and Passive Observations</name>
        <t>The first day of the workshop agenda focused on the existing state of the relationship between network management and encrypted traffic from various angles. Presentations ranged from discussing classifiers using machine-learning machine learning to recognize traffic, to advanced techniques for evading traffic analysis, to user privacy considerations.</t>
        <t>After an introduction that covered the goals of the workshop and the starting questions (as described in <xref target="intro"/>), there were four presentations, presentations followed by open discussion.</t>
        <section anchor="traffic-classification-and-network-management">
          <name>Traffic classification Classification and network management</name> Network Management</name>
          <t>Many existing network management techiques techniques are passive in nature: they don't rely on an explicit signals from end hosts to negotiate with network middleboxes, middleboxes but instead rely on inspecting packets to recognize traffic and apply various policies. Traffic classification, as a passive technique, is being challenged by increasing encryption.</t>
          <t>Traffic classification is commonly performed by networks to infer what applications and services are being used. This information is in turn used for capacity and resource planning, Quality-of-Service (QoS) monitoring, traffic prioritization, network access control, identity management, and malware detection. However, since classification traditionally commonly relies on recognizing unencrypted properties of packets in a flow, increasing encryption of traffic can decrease the effectiveness of classification.</t>
          <t>The amount of classification that can be performed on traffic also provides a useful insight onto into how "leaky" the protocols used by applications are, are and points to areas where information is visible to any observer, which who may be malicious or not.</t>
          <t>Traditionally, may not be malicious.</t>
          <t>Frequently, classification has been based on experts crafting specific rules, rules crafted by experts, but there is also a move toward using maching machine learning to recognize patterns. "Deep learning" machine learning machine-learning models generally rely on analyzing a large set of traffic over time, time and have trouble reacting quickly to changes in traffic patterns.</t>
          <t>Models that are based on closed-world data sets also become less useful over time, time as traffic changes. <xref target="JIANG"/> describes experiments that showed show that a model that performs performed with high accuracy on an initial data set became becomes severely degraded when running on a newer data set that contained contains traffic from the same applications. Even in as little time as one week, the traffic classification would become degraded. However, the set of features in packets and flows that were useful for models stayed mostly consistent, even if the models themselves needed to be updated. Models where the feature space is reduced to fewer features showed better resiliency, resiliency and could be retrained more quickly. Based on this, <xref target="JIANG"/> recommends more work and research on determining to determine which set of features in IP packets are most useful for focused machine learning machine-learning analysis. <xref target="WU"/> also recommends further research investment in Artificial Intelligent Intelligence (AI) analysis for network management.</t>
        </section>
        <section anchor="preventing-traffic-analysis">
          <name>Preventing traffic analysis</name> Traffic Analysis</name>
          <t>Just as traffic classification is continually adapting, techniques to prevent traffic analysis and to obfuscate application and user traffic are continually evolving. An invited talk from the authors of <xref target="DITTO"/> shared a novel approach with the workshop for how to build a very robust system to prevent unwanted traffic analysis.</t>
          <t>Usually traffic obfuscation is performed by changing the timing of packets or by adding padding to data. The practices can be costly and negatively impact performance. DITTO <xref target="DITTO"/> demonstrated the feasibility of applying traffic obfuscation on aggregated traffic in the network with minimal overhead and in line inline speed.</t>
          <t>While traffic obfuscation techniques are today not widely deployed, deployed today, this study underlines, together with underlines the need for continuous effort to keep traffic models updated over time, the challenges of the classification of encrypted traffic traffic, as well as the opportunities to further enhance user privacy.</t>
        </section>
        <section anchor="users-and-privacy">
          <name>Users and privacy</name> Privacy</name>
          <t>The Privacy Enhancements and Assessments Research Group (PEARG) is working on a document to discuss guidelines for how to measure measuring traffic on the Internet in a safe and privacy-friendly way (<xref target="I-D.irtf-pearg-safe-internet-measurement"/>). <xref target="I-D.irtf-pearg-safe-internet-measurement"/>. These guidelines and principles provide another angle onto view on the discussion of passive classification and analysis of traffic.</t>
          <t>Consent for collection and measurement of metadata is an important consideration in deploying network measurement techniques. This consent can be explicitly given explicitly as informed consent, or can be given by proxy proxy, or may be only implied. For example, a user of a network might need to consent to certain measurement and traffic treatment when joining a network.</t>
          <t>Various techniques for data collection can also improve user privacy, such as discarding data after a short period of time, masking out aspects of data that contain user-identifying information, reducing the accuracy of collected data, and aggregating data.</t>
        </section>
        <section anchor="discussion">
          <name>Discussion</name>
          <t>The intents and goals of users, application developers, and network operators align in some cases, but not in others. One of the recurring challenges that came up was not having discussed was the lack of a clear way to understand or to communicate intents and requirements. Both traffic classification and traffic obfuscation attempt to change the visibility of traffic without cooperation of other parties: traffic classification is a an attempt by the network attempting to inspect application traffic without coordination from applications, and traffic obfuscation is an attempt by the application to hide that same traffic as it transits a network.</t>
          <t>Traffic adaptation and prioritization is one dimension in which the incentives for cooperation seem most clear. Even if an application is trying to prevent the leaking of metadata, it could benefit from signals from the network about sudden capacity changes that can help it adapt its application quality, such as bitrates and codecs. Such signalling signaling may not be appropriate for the most privacy-sensitive applications, like Tor, but could be applicable for many others. There are existing protocols that involve explicit signaling between applications and networks, such as Explicit Congestion Notification (ECN) <xref target="RFC3168"/>, but that has yet to see wide adoption.</t>
          <t>Managed networks (such a as private corporate networks) was were brought up in several comments as a particularly challenging area for being able to meet meeting management requirements while maintaining encryption and privacy. These networks can have legal and regulated requirements for detection of specific fraudulent or malicious traffic.</t>
          <t>Personal networks that enable managed parental controls have similar complications with encrypted traffic and user privacy. In these scenarios, the parental controls being that are operated by the network may be as simple as a DNS filter, and which can be made ineffective by a device routing traffic to an alternate DNS resolver.</t>
        </section>
      </section>
      <section anchor="day2">
        <name>“Where we want
        <name>"Where We Want to go” Go" - Collaboration Principles</name>
        <t>The second day of the workshop agenda focused on the emerging techniques for analysing, managing analyzing, managing, or monitoring encrypted traffic. Presentations ranged from discussing covered advanced classification and identification, including machine-learning techniques, for the purposes of manging managing network flows, flows or monitoring or monetising monetizing usage.</t>
        <t>After an introduction that covered the goals of the workshop and the starting questions (as described in <xref target="intro"/>), there were three presentations, followed by open discussion.</t>
        <section anchor="first-party-collaboration-for-network-management">
          <name>First party collaboration
          <name>First-Party Collaboration for network management</name> Network Management</name>
          <t>It is the intention intent of end-to-end encryption of traffic to create a barrier between entities inside the communication channel and everyone else, including network operators, considering end-to-end encryption of traffic. Any attempt, therefore, operators. Therefore, any attempt to overcome that intentional barrier requires an intent to collaborate collaboration between the inside and outside entities. Those entities must, at At a minimum, those entities must agree on the benefits to of overcoming the barrier (or solving the problem), agree that costs are proportional to the benefits, and agree to additional limitations, limitations or safeguards, safeguards against bad behaviour behavior by collaborators including the inclusion of other non-insiders <xref target="BARNES"/>.</t>
          <t>The Internet is designed interoperably, which means an outside entity wishing to collaborate with the inside might be any number of intermediaries and not, say, a specific person that can be trusted in the human sense. Additionally Additionally, the use of encryption, especially network-layer or transport-layer encryption, introduces dynamic or opportunitistic opportunistic or perfunctory discoverability. These realities both point to a need to interrogate the reason ask why any an outside entity might make an engineering case to collaborate with the user of a network with encrypted traffic, traffic and to ask whether the tradeoffs trade-offs and potential risks are worth it to the user.</t>
          <t>However, the answers cannot be specific specific, and the determinations or guidance need to be general as the encryption boundary is inevitably an application used by many people. Tradeoffs Trade-offs must make sense to users who are unlikely to be thinking about network management considerations. Harms need to be preemptively reduced because because, in general terms terms, few users would choose network management benefits over their own privacy if given the choice.</t>
          <t>Some have found that there appears to be little little, if any actual any, evidence
that encryption is causing user-meaningful causes network problems. problems that are meaningful to the user. Since
alignment on problem-solving problem solving is a prerequisite to collaboration on a
solution
solution, it does not seem that collaboration across the encryption
boundary is called for.</t>
        </section>
        <section anchor="second-and-third-party-collaboration-for-network-management">
          <name>Second
          <name>Second- and third party collaboration Third-Party Collaboration for network management</name> Network Management</name>
          <t>Even with the wide-scale deployment of encryption in new protocols and of techniques that prevent passive observers of network traffic from knowing the content of exchanged communications, important information information, such as which parties communicate and sometimes even which services have been requested requested, may still be able to be deduced. The future is to conceal more data and metadata from passive observers and also to minimize information exposure to second parties (where the user is the first party) by, maybe counterintuitively, introducing third-party relay services to intermediate communications. As discussed in <xref target="KUEHLEWIND"/>, the relay is a mechanism to separate (using that uses additional levels of encryption) encryption to separate two important pieces of information: knowledge of the identity of the person accessing a service is separated from knowledge about the service being accessed. By contrast contrast, a VPN uses only one level of encryption and does not separate identity (first party) and service (second party) metadata.</t>
          <t>Relay mechanisms are termed "oblivious", there is a future for specifications in privacy-preserving measurement (PPM), and protocols like Multiplexed Application Substrate over QUIC Encryption (MASQUE) are discussed in the IETF. In various schemes, users are ideally able to share their identity only with the entity they have identified as a trusted one. That data is not shared with the service provider. However However, this is more complicated for network management, but there may be opportunities for better collaboration between the network and, say, the application or service at the endpoint.</t>
          <t>A queriable relay mechanism could preserve network management functions that are disrupted by encryption, such as TCP optimisation, optimization, quality of service, zero-rating, parental controls, access control, redirection, content enhancement, analytics analytics, and fraud prevention. Instead of encrypted encrypting communication between only two ends and with passive observation by all on-path elements, intermediate relays could be introduced as trusted parties with that get to see limited information for the purposes purpose of collaboration between in-network intermediary services' support.</t> services.</t>
        </section>
        <section anchor="visible-optional-network-management">
          <name>Visible, optional network management</name>
          <t>In encrypted communications, out Optional Network Management</name>
          <t>Out of all of the possible network management functions that might be ameliorated by proxying, the ability to control congestion in encrypted communications has been researched in depth. These techniques are realized based on TCP performance enhancing performance-enhancing proxies (PEP) (PEPs) that either entirely intercept a TCP connection or interfere with the transport information in the TCP header. However, despite the challenge that the new encrypted protocol will limit any such in-network interference, these techniques can also have a negative impact on the evolvability of these protocols. Therefore, instead of manipulating existing information, a new approach was presented  where where, instead of manipulating existing information, additional information is send sent using a so-called side-car sidecar protocol independent of the main transport protocol that is used end-to-end end to end <xref target="WELZL"/>. E.g. side car For example, sidecar information can contain additional acknowledgements acknowledgments to enable in-network local retransmission or faster end-to-end retransmission by reducing the signaling round trip round-trip time.</t>
          <t>Taking user privacy benefits for granted, there is a need to investigate the comparable performance outputs of various encrypted traffic configurations such as the use of an additional "side-car" sidecar protocol, or explicit encrypted and trusted network communication using MASQUE in relation to existing techniques such as TCP performance enhancing proxies (PEP), PEPs, etc.</t>
        </section>
        <section anchor="discussion-1">
          <name>Discussion</name>
          <t>One size fits all? On the issue of trust, different networks or devices are going to will have different trust requirements for the level of trust that they have in devices, users users, or each other, and vice versa. For example, imagine two networks with really different security requirements, like protecting children in a home network with a requirement to protect its child users versus a national security institution. institution's network. How could one network architecture solve the needs of all use cases?</t>
          <t>Does our destination have consequences? It seems sometimes that there may be future consequences many years down caused by the line of ubiquitous, strong encryption of network traffic because it will cause a reaction by intermediaries to find ways to poke holes in what are supposed to be long-term solutions for user privacy and security.</t>
          <t>Can we bring the user along? While there has been a focus on the good reasons for why people might collaborate across the encryption barrier, there will always be others who want to disrupt that because they are motivated in order to exploit the data for their own gain, and sometimes this exploitation is called innovation. What high-level High-level policy mitigations have done is to expose exposed how powerless end users are to against corporate practices of data harvesting. And yet interfaces to help users understand these lower layer lower-layer traffic flows to protect their financial transactions or privacy haven't been achieved yet. That means that engineers are having to must make inferences about what users want. Instead user wants. Instead, we should be making make these relationships and tradeoffs trade-offs more visible.</t>
        </section>
      </section>
      <section anchor="day3">
        <name>“How we get there”
        <name>"How We Get There" - Collaboration Use cases</name> Cases</name>
        <t>The third day focused on techniques that could actually be used to
improve the management of encrypted networks.  A central theme of all of
the presentations about networks.<br/>
The potential proposed paths forward described in the presentations included some
element of collaboration between the networks and the subscribing clients that
simultaneously want both privacy and protection.  Thus, the central
theme in of the third day became negotiation and collaboration.</t>
        <section anchor="establishing-expected-contracts-to-enable-security-management">
          <name>Establishing expected contracts Expected Contracts to enable security management</name>
          <t>When thinking about Enable Security Management</name>
          <t>For enterprise networks where client behavior is
potentially managed, <xref target="COLLINS"/> proposes "Improving network
monitoring through contracts", where contracts describe different
states of network behavior.</t>
          <t>Because network operators have a limited amount of time to focus on
problems and process alerts, contracts and states let the operator
focus on a particular aspect of a current situation or problem.  The
current estimate for the number of events a Security Operations Center (SOC) operator can handle
is about 10 per hour.  Operators must work within the limits imposed
by their organization, organization and must pick between among options that frequently
only frustrate attackers -- entirely preventing attacks entirely is potentially
impossible. Finally, operators must prioritize and manage the most
events possible.</t>
          <t>Validating which alerts are true positives is challenging because lots
of weird traffic creates many anomalies anomalies, and not all anomalies are
malicious events.  Identifying what which anomalous traffic is rooted in
malicious activity with any level of certainty is extremely
challenging.  Unfortunately, applying the latest machine learning machine-learning
techniques has only produced mixed results.  To make matters worse,
the large amounts of Internet-wide scanning has resulted in endless
traffic that is technically malicious but only creates an information
overload and challenges event prioritization.  Any path forward must
succeed in freeing
free up analyst time to concentrate on the more
challenging events.</t>
          <t>The proposed contract solution is to define a collection of acceptable
behaviors categorized into an envelope of that comprises different states that might
include IP addresses, domain names, and indicators of compromise.
Deviation from a contract might indicate that a system is acting
outside a normal mode of behavior, behavior or even that a normal mode of
behavior is suddenly missing.  An example contract might be "this
system is expected to update its base OS once a day", and if day". If this
doesn't occur occur, then this expectation has not been met met, and the system
should be checked as it failed to call home to look for (potentially
security related)
security-related) updates.</t>
          <t>Within the IETF, the Manufacturer Usage Description Specification
(MUD) {?RFC8520} specification <xref target="RFC8520"/> is one subset of contracts.  Note that
contracts are likely to only succeed only in a constrained, expected
environment maintained by operational staff, staff and may not work in an
open internet Internet environment where end users are driving drive all network
connections.</t>
        </section>
        <section anchor="zero-knowledge-middleboxes">
          <name>Zero Knowledge
          <name>Zero-Knowledge Middleboxes</name>
          <t>The world is not only shifting to increased encrypted traffic but is
also encrypting more and more of the metadata (e.g. (e.g., DNS queries and
responses).  This makes network policy enforcement by middleboxes
significantly more challenging.  The result is the creation of a
significant tension between security enforcement and privacy
protection.</t>
          <t>A goal
          <t>Goals for solving this problem should include not weakening
encryption, should enable
enabling networks to enforce their policies, and but
should ideally not require newly deployed include the weakening of encryption nor the deployment of new server software.  Existing
solutions fail with to meet at least one of these points.</t>
          <t>A cryptographic principle of a "zero-knowledge proof" (ZKP) <xref target="GRUBBS"/>
maybe
may be one path forward to consider.  A ZKP allows a third party to
verify that a statement is true, true without revealing what the statement
actually is.  Applying this to network traffic has been shown to allow
a middlebox to verify that traffic to a web server is actually
compliant with a policy without revealing the actual contents.  This
solution meets the above three criteria. criteria listed above.  Using ZKP within TLS 1.3
traffic turns out to be plausible.</t>
          <t>An example engine using encrypted DNS was built to test ZKP using encrypted DNS. ZKP.  Clients
were able to create DNS requests that were not listed within a DNS
block list.  Middleboxes could verify, without knowing the exact
request, that the client's DNS request was not in on the prohibited list.
Although the result was functional, the computational overhead was
still too slow slow, and future work will be needed to decrease the ZKP
imposed ZKP-imposed
latencies.</t>
        </section>
        <section anchor="red-rover-a-collaborative-approach-to-content-filtering">
          <name>Red Rover - A collaborative approach a Collaborative Approach to content filtering</name> Content Filtering</name>
          <t>The principle challenge being studied is how to deal with handle the inherit inherent
conflict between filtering and privacy.  Network operators need to
implement policies and regulations that can originate from many
locations (e.g. (e.g., security, governmental, parental, etc). etc.).  Conversely,
clients need to protect user's their users' privacy and user security.</t>
          <t>Safe browsing, originally created by Google, is one example of a
mechanism that tries to meet both sides of this conflict.  It would be
beneficial to standardize this and other similar mechanisms.
Operating systems could continually protect their users by ensuring
that malicious destinations are not being reached.  This would require
some coordination between cooperating clients and servers offering
protection services.  These collaborative solutions may be the best
compromise between to resolve the tension of between privacy vs services and protection based services
<xref target="PAULY"/>.</t>
        </section>
      </section>
    </section>
    <section anchor="conclusions">
      <name>Conclusions</name>
      <t>Looking forward, the workshop participants identified that solving the
entire problem space with a single approach will be challenging for
several reasons:</t>
      <ul spacing="normal">
        <li>The
        <li>
          <t>The scalability of many solutions will likely be an issue as some
solutions are complex or expensive to implement.</li>
        <li>Collaboration implement.</t>
        </li>
        <li>
          <t>Collaboration between multiple parties will be required for many
mechanisms to function, and the sets of parties required for different
use cases might be disjoint.</li>
        <li>There disjoint.</t>
        </li>
        <li>
          <t>There is an unanswered question of whether or not network operators
be are willing to participate and allow by allowing new encryption technologies into their environment
requirements in exchange for technologies that prove their clients are being good net-citizens. If so, some of these solutions might be required to exist before networks allow a certain type of increased encryption; consider the example of TLS Encrypted Client Hello being blocked by some network operators.</li> operators.</t>
        </li>
      </ul>
      <t>The breadth of the problem space itself is another complicating
factor.  There is a wide variety of network architectures, and each
has different requirements for both data encryption and network
management.  Each problem space will have multiple, different encumbrances of
multiple types; encumbrances:
for example, technical, legal, data ownership,
and regulatory concerns.  New network architectures might be needed to
solve this problem at a larger scope, which would in turn require
interoperability support from network product vendors.  Education about
various solutions will be required in order to ensure regulation and
policy organizations can understand and thus support the deployment of
developed solutions.</t>
      <t>After new technologies and related standards are developed and deployed,
unintended consequences can emerge that weren't considered during the
design of the protocol. emerge.
These lead to effects in multiple directions:
on one hand, exposed protocol values not intended for network management
might be used by networks to differentiate traffic; on the other hand,
changes to a protocol that break existing use cases might have an impact on private network deployments
that break existing use cases. deployments.
While making decisions on technology
direction and protocol design, it is important to consider the impact on
various kinds of network deployments and their unique requirements.
When protocols change to make different network management functions
easier or harder, the impact on various deployment models ought to be
considered and documented.</t>
    </section>
  </middle>
  <back>
    <references>
    <displayreference target="I-D.irtf-pearg-safe-internet-measurement" to="LEARMONTH"/>

    <references anchor="sec-informative-references">
      <name>Informative References</name>
      <reference anchor="BARNES" target="https://github.com/intarchboard/m-ten-workshop/blob/main/papers/Barnes-Whats-In-It-For-Me-Revisiting-the-reasons-people-collaborate.pdf"> target="https://www.iab.org/wp-content/IAB-uploads/2023/11/Barnes-Whats-In-It-For-Me-Revisiting-the-reasons-people-collaborate.pdf">
        <front>
          <title>What’s
          <title>What's In It For Me? Revisiting the reasons people collaborate</title>
          <author initials="R." surname="Barnes" fullname="Richard L. Barnes">
            <organization/>
          </author>
          <date year="2022" month="August"/>
        </front>
      </reference>
      <reference anchor="CASAS" target="https://github.com/intarchboard/workshop-m-ten/blob/main/papers/Casas-AI-driven-real-time-QoE-monitoring-encrypted-traffic.pdf"> target="https://www.iab.org/wp-content/IAB-uploads/2023/11/Casas-AI-driven-real-time-QoE-monitoring-encrypted-traffic.pdf">
        <front>
          <title>Monitoring User-Perceived Quality in an Encrypted Internet</title> Internet - AI to the Rescue</title>
          <author initials="P." surname="Casas" fullname="Pedro Casas">
            <organization/>
          </author>
          <date year="2022" month="August"/>
        </front>
      </reference>
      <reference anchor="COLLINS" target="https://github.com/intarchboard/workshop-m-ten/blob/main/papers/Collins-Improving-Network-Monitoring-Through-Contracts.pdf"> target="https://www.iab.org/wp-content/IAB-uploads/2023/11/Collins-Improving-Network-Monitoring-Through-Contracts.pdf">
        <front>
          <title>Improving Network Monitoring Through Contracts</title>
          <author initials="M." surname="Collins" fullname="Michael Collins">
            <organization/>
          </author>
          <date year="2022" month="August"/>
        </front>
      </reference>
      <reference anchor="DERI" target="https://github.com/intarchboard/workshop-m-ten/blob/main/papers/Deri-nDPI-Research-Proposal.pdf"> target="https://www.iab.org/wp-content/IAB-uploads/2023/11/Deri-nDPI-Research-Proposal.pdf">
        <front>
          <title>nDPI Research Proposal</title>
          <author initials="L." surname="Deri" fullname="Luca Deri">
            <organization/>
          </author>
          <date year="2022" month="August"/>
        </front>
      </reference>
      <reference anchor="ELKINS" target="https://github.com/intarchboard/workshop-m-ten/blob/main/papers/Elkins-Performance-Monitoring-in-Encrypted-Networks-PDMv2.pdf"> target="https://www.iab.org/wp-content/IAB-uploads/2023/11/Elkins-Performance-Monitoring-in-Encrypted-Networks-PDMv2.pdf">
        <front>
          <title>Performance Monitoring in Encrypted Networks</title> Networks: PDMv2</title>
          <author initials="N." surname="Elkins" fullname="Nalini Elkins">
            <organization/>
          </author>
          <author initials="M." surname="Ackermann" fullname="Mike Ackermann">
            <organization/>
          </author>
          <author initials="M." surname="Tahiliani" fullname="Mohit P. Tahiliani">
            <organization/>
          </author>
          <author initials="D." surname="Dhody" fullname="Dhruv Dhody">
            <organization/>
          </author>
          <author initials="T." surname="Pecorella" fullname="Prof. Tommaso Pecorella">
            <organization/>
          </author>
          <date year="2022" month="August"/>
        </front>
      </reference>
      <reference anchor="GRUBBS" target="https://github.com/intarchboard/workshop-m-ten/blob/main/papers/Grubbs-Zero-Knowledge%20Middleboxes.pdf"> target="https://www.usenix.org/conference/usenixsecurity22/presentation/grubbs">
        <front>
          <title>Zero-Knowledge Middleboxes</title>
          <author initials="P." surname="Grubbs" fullname="Paul Grubbs">
            <organization/>
          </author>
          <author initials="A." surname="Arun" fullname="Arasu Arun">
            <organization/>
          </author>
          <author initials="Y." surname="Zhang" fullname="Ye Zhang">
            <organization/>
          </author>
          <author initials="J." surname="Bonneau" fullname="Joseph Bonneau">
            <organization/>
          </author>
          <author initials="M." surname="Walfish" fullname="Michael Walfish">
            <organization/>
          </author>
          <date year="2022" month="August"/>
        </front>
        <refcontent>31st USENIX Security Symposium (USENIX Security 22)</refcontent>
      </reference>
      <reference anchor="JIANG" target="https://github.com/intarchboard/workshop-m-ten/blob/main/papers/Jiang-Towards-Designing-Robust-and-Efficient-Classifiers-for-Encrypted-Traffic-in-the-Modern-Internet.pdf"> target="https://www.iab.org/wp-content/IAB-uploads/2023/11/Jiang-Towards-Designing-Robust-and-Efficient-Classifiers-for-Encrypted-Traffic-in-the-Modern-Internet.pdf">
        <front>
          <title>Towards Designing Robust and Efficient Classifiers for Encrypted Traffic in the Modern Internet</title>
          <author initials="X." surname="Jiang" fullname="Xi Jiang">
            <organization/>
          </author>
          <author initials="S." surname="Liu" fullname="Shinan Liu">
            <organization/>
          </author>
          <author initials="S." surname="Naama" fullname="Saloua Naama">
            <organization/>
          </author>
          <author initials="F." surname="Bronzino" fullname="Francesco Bronzino">
            <organization/>
          </author>
          <author initials="P." surname="Schmitt" fullname="Paul Schmitt">
            <organization/>
          </author>
          <author initials="N." surname="Feamster" fullname="Nick Feamster">
            <organization/>
          </author>
          <date year="2022" month="August"/>
        </front>
      </reference>
      <reference anchor="KNODEL" target="https://github.com/intarchboard/workshop-m-ten/blob/main/papers/Knodel-Guidelines-for-Performing-Safe-Measurement-on-the-Internet.pdf"> target="https://www.iab.org/wp-content/IAB-uploads/2023/11/Knodel-Guidelines-for-Performing-Safe-Measurement-on-the-Internet.pdf">
        <front>
          <title>Guidelines
          <title>(Introduction) 'Guidelines for Performing Safe Measurement on the Internet</title> Internet'</title>
          <author initials="M." surname="Knodel" fullname="Mallory Knodel">
            <organization/>
          </author>
          <date year="2022" month="August"/>
        </front>
      </reference>

      <reference anchor="KUEHLEWIND" target="https://github.com/intarchboard/workshop-m-ten/blob/main/papers/Kuehlewind-Relying-on-Relays.pdf"> target="https://www.ericsson.com/en/blog/2022/6/relays-and-online-user-privacy">
        <front>
          <title>Relying on Relays</title> Relays: The future of secure communication</title>
          <author initials="M." surname="Kühlewind" surname="Kuehlewind" fullname="Mirja Kühlewind"> Kuehlewind">
            <organization/>
          </author>
          <author initials="M." surname="Westerlund" fullname="Magnus Westerlund">
            <organization/>
          </author>
          <author initials="Z." surname="Sarker" fullname="Zaheduzzaman Sarker">
            <organization/>
          </author>
          <author initials="M." surname="Ihlar" fullname="Marcus Ihlar">
            <organization/>
          </author>
          <date year="2022" month="August"/> month="June"/>
        </front>
      </reference>
      <reference anchor="LEI" target="https://github.com/intarchboard/workshop-m-ten/blob/main/papers/Lei-Encrypted-Traffic-Classification-Through-Deep-Learning.pdf"> target="https://www.iab.org/wp-content/IAB-uploads/2023/11/Lei-Encrypted-Traffic-Classification-Through-Deep-Learning.pdf">
        <front>
          <title>Encrypted Traffic Classification Through Deep Learning</title>
          <author initials="Y." surname="Lei" fullname="Yupeng Lei">
            <organization/>
          </author>
          <author initials="J." surname="Wu" fullname="Jun Wu">
            <organization/>
          </author>
          <author initials="X." surname="Sun" fullname="Xudong Sun">
            <organization/>
          </author>
          <author initials="L." surname="Zhang" fullname="Liang Zhang">
            <organization/>
          </author>
          <author initials="Q." surname="Wu" fullname="Qin Wu">
            <organization/>
          </author>
          <date year="2022" month="August"/>
        </front>
      </reference>
      <reference anchor="PAULY" target="https://github.com/intarchboard/workshop-m-ten/blob/main/papers/Pauly-Red-Rover-A-collaborative-approach-to-content-filtering.pdf"> target="https://www.iab.org/wp-content/IAB-uploads/2023/11/Pauly-Red-Rover-A-collaborative-approach-to-content-filtering.pdf">
        <front>
          <title>Red Rover</title> Rover: A collaborative approach to content filtering</title>
          <author initials="T." surname="Pauly" fullname="Tommy Pauly">
            <organization/>
          </author>
          <author initials="R." surname="Barnes" fullname="Richard Barnes">
            <organization/>
          </author>
          <date year="2022" month="August"/>
        </front>
      </reference>
      <reference anchor="WELZL" target="https://github.com/intarchboard/workshop-m-ten/blob/main/papers/Welzl-The-Sidecar-Opting-in-to-PEP-Functions.pdf"> target="https://www.iab.org/wp-content/IAB-uploads/2023/11/Welzl-The-Sidecar-Opting-in-to-PEP-Functions.pdf">
        <front>
          <title>The Sidecar</title> Sidecar: 'Opting in' to PEP Functions</title>
          <author initials="M." surname="Welzl" fullname="Michael Welzl">
            <organization/>
          </author>
          <date year="2022" month="August"/>
        </front>
      </reference>
      <reference anchor="WU" target="https://github.com/intarchboard/workshop-m-ten/blob/main/papers/Wu-mten-taxonomy.pdf"> target="https://www.iab.org/wp-content/IAB-uploads/2023/11/Wu-mten-taxonomy.pdf">
        <front>
          <title>Network Management of Encrypted Traffic</title> Traffic: Detect it don't decrypt it</title>
          <author initials="Q." surname="Wu" fullname="Qin Wu">
            <organization/>
          </author>
          <author initials="J." surname="Wu" fullname="Jun Wu">
            <organization/>
          </author>
          <author initials="Q." surname="Ma" fullname="Qiufang Ma">
            <organization/>
          </author>
          <date year="2022" month="August"/>
        </front>
      </reference>
      <reference anchor="DITTO" target="https://nsg.ee.ethz.ch/fileadmin/user_upload/publications/ditto_final_ndss22.pdf"> anchor="DITTO">
        <front>
          <title>Ditto -
          <title>ditto: WAN Traffic Obfuscation at Line Rate</title>
          <author initials="R." surname="Meier" fullname="Roland Meier">
            <organization/>
          </author>
          <author initials="V." surname="Lenders" fullname="Vincent Lenders">
            <organization/>
          </author>
          <author initials="L." surname="Vanbever" fullname="Laurent Vanbever">
            <organization/>
          </author>
          <date year="2022" month="April"/>
        </front>
      </reference>
      <reference anchor="I-D.irtf-pearg-safe-internet-measurement">
        <front>
          <title>Guidelines for Performing Safe Measurement on the Internet</title>
          <author fullname="Iain R. Learmonth" initials="I. R." surname="Learmonth">
            <organization>HamBSD</organization>
          </author>
          <author fullname="Gurshabad Grover" initials="G." surname="Grover">
            <organization>Centre for Internet
        <refcontent>Network and Society</organization>
          </author>
          <author fullname="Mallory Knodel" initials="M." surname="Knodel">
            <organization>Center for Democracy and Technology</organization>
          </author>
          <date day="10" month="July" year="2023"/>
          <abstract>
            <t>   Internet measurement is important to researchers from industry,
   academia and civil society.  While measurement of the internet can
   give insight into the functioning and usage of the Internet, it can
   present risks to user privacy.  This document describes briefly those
   risks and proposes guidelines for ensuring that internet measurements
   can be carried out safely, with examples.

            </t>
          </abstract>
        </front> Distributed Systems Security (NDSS) Symposium</refcontent>
        <seriesInfo name="Internet-Draft" value="draft-irtf-pearg-safe-internet-measurement-08"/> name="DOI" value="10.14722/ndss.2022.24056"/>
      </reference>

      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.irtf-pearg-safe-internet-measurement"/>

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8520.xml"/>
      <reference anchor="RFC3168"> anchor="HARDAKER" target="https://www.iab.org/wp-content/IAB-uploads/2023/11/Hardaker-Encrypted-Traffic-Estimation.pdf">
        <front>
          <title>The Addition of Explicit Congestion Notification (ECN) to IP</title>
          <author fullname="K. Ramakrishnan" initials="K." surname="Ramakrishnan"/>
          <author fullname="S. Floyd" initials="S." surname="Floyd"/>
          <title>Network Flow Management by Probability</title>
          <author fullname="D. Black" initials="D." surname="Black"/> initials="W." surname="Hardaker" fullname="Wes Hardaker">
            <organization/>
          </author>
          <date month="September" year="2001"/>
          <abstract>
            <t>This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK]</t>
          </abstract> year="2022" month="August"/>
        </front>
        <seriesInfo name="RFC" value="3168"/>
        <seriesInfo name="DOI" value="10.17487/RFC3168"/>
      </reference>
    </references>

<section anchor="positionpapers">
      <name>Position Papers</name>
      <t>Interested participants were openly invited to submit position papers on the workshop topics, including Internet-Drafts, relevant academic papers, or short abstracts explaining their interest. The papers below constitute the inputs that were considered relevant for workshop attendees and that focused the discussions themselves. The program committee grouped the papers by theme as such.</t> theme.</t>
      <section anchor="motivations-and-principles">
        <name>Motivations and principles</name> Principles</name>
        <t>Richard Barnes. “What’s "What's In It For Me? Revisiting the reasons people collaborate.” collaborate." <xref target="BARNES"/></t>
        <t>Iain R. Learmonth, Gurshabad Grover, Mallory
        <t>Mallory Knodel. “Guidelines "(Introduction) 'Guidelines for Performing Safe Measurement on the Internet.” Internet'." (Additional rationale) <xref target="KNODEL"/></t>
        <t>Qin Wu, Jun Wu, Qiufang Ma. “Network "Network Management of Encrypted Traffic: Detect it don’t don't decrypt it.” it." <xref target="WU"/></t>
      </section>
      <section anchor="classification-and-identification-of-encrypted-traffic">
        <name>Classification and identification Identification of encrypted traffic</name> Encrypted Traffic</name>
        <t>Luca Deri. “nDPI "nDPI Research Proposal.” Proposal." <xref target="DERI"/></t>
        <t>Wes Hardaker. “Network "Network Flow Management by Probability.”</t> Probability." <xref target="HARDAKER"/></t>
        <t>Xi Jiang, Shinan Liu, Saloua Naama, Francesco Bronzino, Paul Schmitt, Nick Feamster. “Towards "Towards Designing Robust and Efficient Classifiers for Encrypted Traffic in the Modern Internet.” Internet." <xref target="JIANG"/></t>
        <t>Yupeng Lei, Jun Wu, Xudong Sun, Liang Zhang, Qin Wu. “Encrypted "Encrypted Traffic Classification Through Deep Learning.” Learning." <xref target="LEI"/></t>
      </section>
      <section anchor="ideas-for-collaboration-and-coordination-between-devices-and-networks">
        <name>Ideas for collaboration Collaboration and coordination Coordination between devices Devices and networks</name> Networks</name>
        <t>Michael Collins. “Improving "Improving Network Monitoring Through Contracts.” Contracts." <xref target="COLLINS"/></t>
        <t>Paul Grubbs, Arasu Arun, Ye Zhang, Joseph Bonneau, Michael Walfish. “Zero-Knowledge Middleboxes.” "Zero-Knowledge Middleboxes." <xref target="GRUBBS"/></t>
        <t>Mirja Kühlewind, Kuehlewind, Magnus Westerlund, Zaheduzzaman Sarker, Marcus Ihlar. “Relying "Relying on Relays: The future of secure communication.” communication." <xref target="KUEHLEWIND"/></t>
        <t>Tommy Pauly, Richard Barnes. “Red "Red Rover: A collaborative approach to content filtering.” filtering." <xref target="PAULY"/></t>
        <t>Michael Welzl. “The "The Sidecar: ‘Opting in’ 'Opting in' to PEP Functions.“ Functions." <xref target="WELZL"/></t>
      </section>
      <section anchor="other-background-material">
        <name>Other background material</name> Background Material</name>
        <t>Pedro Casas. “Monitoring "Monitoring User-Perceived Quality in an Encrypted Internet – - AI to the Rescue.” Rescue." <xref target="CASAS"/></t>
        <t>Nalini Elkins, Mike Ackermann, Mohit P. Tahiliani, Dhruv Dhody, Prof. Tommaso Pecorella. “Performance "Performance Monitoring in Encrypted Networks: PDMv2.” PDMv2." <xref target="ELKINS"/></t>
      </section>
    </section>
    <section anchor="participants">
      <name>Workshop participants</name> Participants</name>
      <t>The workshop participants were Cindy Morgan, Colin Perkins, Cullen Jennings, Deborah Brungard, Dhruv Dhody, Eric Vyncke, Georg Carle, Ivan Nardi, Jari Arkko, Jason Livingood, Jiankang Yao, Karen O'Donoghue, Keith Winstein, Lars Eggert, Laurent Vanbever, Luca Deri, Mallory Knodel, Marcus Ihlar, Matteo, Michael Ackermann, Michael Collins, Michael Richardson, Michael Welzl, Mike Ackermann, Mirja Kühlewind, Mohit <contact fullname="Cindy Morgan"/>, <contact fullname="Colin Perkins"/>, <contact fullname="Cullen Jennings"/>, <contact fullname="Deborah Brungard"/>, <contact fullname="Dhruv Dhody"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Georg Carle"/>, <contact fullname="Ivan Nardi"/>, <contact fullname="Jari Arkko"/>, <contact fullname="Jason Livingood"/>, <contact fullname="Jiankang Yao"/>, <contact fullname="Karen O'Donoghue"/>, <contact fullname="Keith Winstein"/>, <contact fullname="Lars Eggert"/>, <contact fullname="Laurent Vanbever"/>, <contact fullname="Luca Deri"/>, <contact fullname="Mallory Knodel"/>, <contact fullname="Marcus Ihlar"/>, <contact fullname="Matteo"/>, <contact fullname="Michael Collins"/>, <contact fullname="Michael Richardson"/>, <contact fullname="Michael Welzl"/>, <contact fullname="Mike Ackermann"/>, <contact fullname="Mirja Kühlewind"/>, <contact fullname="Mohit P. Tahiliani, Nalini Elkins, Patrick Tarpey, Paul Grubbs, Pedro Casas, Qin Wu, Qiufang, Richard Barnes, Rob Wilton, Russ White, Saloua Naama, Shinan Liu, Srinivas C, Toerless Eckert, Tommy Pauly, Wes Hardaker, Xi Tahiliani"/>, <contact fullname="Nalini Elkins"/>, <contact fullname="Patrick Tarpey"/>, <contact fullname="Paul Grubbs"/>, <contact fullname="Pedro Casas"/>, <contact fullname="Qin Wu"/>, <contact fullname="Qiufang Ma"/>, <contact fullname="Richard Barnes"/>, <contact fullname="Rob Wilton"/>, <contact fullname="Russ White"/>, <contact fullname="Saloua Naama"/>, <contact fullname="Shinan Liu"/>, <contact fullname="Srinivas C"/>, <contact fullname="Toerless Eckert"/>, <contact fullname="Tommy Pauly"/>, <contact fullname="Wes Hardaker"/>, <contact fullname="Xi Chase Jiang, Zaheduzzaman Sarker, Jiang"/>, <contact fullname="Zaheduzzaman Sarker"/>, and Zhenbin Li.</t> <contact fullname="Zhenbin Li"/>.</t>
    </section>
    <section anchor="program-committee">
      <name>Program Committee</name>
      <t>The workshop program committee members were Wes Hardaker <contact fullname="Wes Hardaker"/> (IAB, USC/ISI), Mallory Knodel <contact fullname="Mallory Knodel"/> (IAB, Center for Democracy and Technology), Mirja Kühlewind <contact fullname="Mirja Kühlewind"/> (IAB, Ericsson), Tommy Pauly <contact fullname="Tommy Pauly"/> (IAB, Apple), Russ White <contact fullname="Russ White"/> (IAB, Juniper), Qin Wu <contact fullname="Qin Wu"/> (IAB, Huawei).</t>
    </section>
    <section numbered="false" anchor="acknowledgments"> anchor="iab-members" numbered="false">
      <name>IAB Members at the Time of Approval</name>
      <t>Internet Architecture Board members at the time this document was approved for publication were:</t>
      <ul empty="true" spacing="compact">
	<li><t><contact fullname="Dhruv Dhody"/></t></li>
	<li><t><contact fullname="Lars Eggert"/></t></li>
	<li><t><contact fullname="Wes Hardaker"/></t></li>
	<li><t><contact fullname="Cullen Jennings"/></t></li>
	<li><t><contact fullname="Mallory Knodel"/></t></li>
	<li><t><contact fullname="Suresh Krishnan"/></t></li>
	<li><t><contact fullname="Mirja Kühlewind"/></t></li>
	<li><t><contact fullname="Tommy Pauly"/></t></li>
	<li><t><contact fullname="Alvaro Retana"/></t></li>
	<li><t><contact fullname="David Schinazi"/></t></li>
	<li><t><contact fullname="Christopher Wood"/></t></li>
	<li><t><contact fullname="Qin Wu"/></t></li>
	<li><t><contact fullname="Jiankang Yao"/></t></li>
      </ul>
    </section>
    <section anchor="acknowledgments" numbered="false">
      <name>Acknowledgments</name>
      <t>TODO acknowledge.</t>
      <t>We wish to acknowledge the comments and suggestions from <contact fullname="Elliot Lear"/> and <contact fullname="Arnaud Taddei"/> for their comments and improvements to this document.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA8193XLkRrLePZ6iggpbQ0d3z0ob9jmHGw4tRVJaSvNDDWc0
u7rZQAPV3ViigT4ogJzWxETsO5yb4wj7TXznN9kncX6ZWT9AN1ej9Ths3WjY
AApVWVmZX36ZVZjP51lf9bU9Myev7K7terPq2q3pN9Zcn39tHtruzm3anWkb
8zxv8rXd2qY3r22xaap/HawzVWOumqLb73pbmhe25yfMk+fz11cvTk+yfLns
7D21zj/E9jp+2UlW5L1dt93+jBpatVlWtkWTb6k7ZZev+nmVL+fbeW+buX9y
/psvMzcst5VzVdv0+x3dSz3NmmG7tN1ZVlKDZ1nRNs42bnBnpu8Gm1EPfpt9
ZvLO5mfm/NXVOf2BFtddO+zOzNtvzVv6q2rW5lv8kt3ZPV0uzzIzN1aGR2/D
X40M0WyDNLJ72wz0zs+MCc3hD+nbuF36eZtXNW75vX2Xb3e1XRTtFr/nXbE5
M5u+37mzp0+Ti0+pOWq66jfDkgRZNT1uXbZ5Vz6dyGY3LOuqOKHbaxKD6+l2
32D62EIaW1Tt8QaePib8xabf1idZlg/9pu0gHXqVoakjOT9fmO+btrQ1/7Qa
6lom8nle1zTB6cW2W+dN9XMOmZ6ZC5Kh7cyq7cyl3bZFlxd78x9Fx9q6Xe/5
GSty295xM78vyn5BzYx68HZh/kCjy+9sN+nDW1LU0SVtrbL96vcbveAWNLej
Bl8vzE0+1PtJa6/b7XafXNHGTvodfvp9vtOJI0E1bbelYd6TemRQ8PCXMV+f
v3pxdXvGLdDUrG0fZ1/nB5P/d6b76bJul0/p5c3TXb6jATz9Ou8a6+ZvN3nv
5tfN/Lqff9N28+d2/sreV67qSRPntLbntA4cLZH5zrbU2XnR1nW+bDtSmsWu
XEmfxCygrb/99b85c92Y695Qc+a5/crE9thWaHtG2jNJe9xW0Bf+b67/Vymb
VwsjHQ+/i5xfVQXmxjwbXecFbs6H9eB68+Vvvvwyo58vzm/Pf6Usg86zUA9l
eZG73M3Pr+dlRzPWQGT1vK+2dv5DezXftk3Vtx3kab35m/e0bFZVMRXh83Cv
eeNsN7+xXWGpzdL8MOR11e9hRPPUjl5jRbA2/qLwbhaGezqR3Y0tuza5clxq
L589u37xqeVGc09dm19vd117DwGpV5hHOcxfb8gcrjfzCzLhtN57N5VZeNr7
lFSK+rQJT3+EnMg8ac8mknoOLbP16OpRaV1evbr+tKK6tF01by5vrml5Oovn
5jddu2tdXk/lgbuMv8v4uz5i3LR48JrJoJ8NRR5/Pzrcq2fff3LduKrvoBq0
ANgUNoVNlaJq5mEJeKWhmy+f3385FUfSQqoYR8HIRwjpxcJI1yZiekHLs6nG
144o1nlB7oM60xyo1p09uHjk+df5pqorconT59tN1WOFT2+YtnFJk7xpy/3k
+ctNN9yPrkwfhIezRdtZstdTC9K1qwX7OjLtk7uOKsy3r958/fUnVphvu2G5
dPOfbNfOCUA81LZc2//w5W+eV2VZ22X7zh5YjvG9Jrnz46ypvHIqDPLs4yvT
J89JDbphqgHnXe6G9ML0sT8tzE+bvFlPnvuTHf08feo78oht09h8mDz3Xevs
bjO5eETj3ub1qnKbR0xhevXoVH93ff7i208709+RepNfaB/oZje/tK5aNzAK
r9olvXmeN+X8Cs61IrQ4v6hzgv+rih6ckx1IzMZrccGwJcA5zwksdoSD1J9O
dUVfZ8LrjLyOvHFpwutM8jqGqdHG6OtgeACD5HW/xn3/cWF45JOZ+GM1+nn6
1O3CPKumc3+7qRpCEfHCkade5Pl2utBv87od8tGl6ZPfkL51bfNz1bSTh7/p
YINd0U5vOLKybovNtur7Y0trfOmIef7G5lvXK3qPD7+oirvxtaP6+v2Ll5dX
zz6twko8M/92qOh/FWA3NFEdEzT3Nl+RAhIwHjqOE+et6ORjyhhbYiWLLRm0
ZJKWEI1zhP7xejaOzpIlfxidHZfgm6s/PLt6e/3i8hNLcbCb2j5UtLxf2XoP
uZGY6J/5/sCy6w0YvdzwkeP+X/9TX3Fg7rq/5IeXj5lLC/2qh8Mm8nUzuMPr
0zZ+Iu3Pu7sD/f0p39hy+PlnWnrN+I4jvbje1Pm0geckaupAvHR09p5dfWLk
+sxWR4yut5MFR/YB5F9au5s/I+QKCzud1ENbOm4lgH20YnwrHzHz5Fmpl1O/
OuwsaVC8cMSzvj1wqkMTfzxiwG8P3P4fh7LFun3U7T877vafweb/Xc//w5H+
/VCF/h2d/ZvzN8/+9Gnnn8kPWqa0att7CmnPEwqBItt5vqPwLad4pm/pCpkp
Mn+rqqZFckQFqBnDzXzErI4omSiCKSXz60mGX2IY3l49++kTe5C3tv65plVi
57dk+Yu8m7/c9RoIkdxurm7m3wxNgVVwYAvpKaNPfZwV5Jc9hvfCteNDf/OJ
xz3Mt+Cx+vxd27Tb/XRsIeKPhHO7OjQUHzHuX1gtn2D50xueTwHVD9Wwwjp+
/neCpcvr169fHhdr49YLaxe23/y8KDZPadnYvCQc8HRwtvvzsKvbvHwqRC1b
SPe0JOjU/nlF8K/+c1M69+VBvHyJO8zcvD1/Eezsy+VqcGpk855sT2PNq49m
7J7b6sCbvWprAOf00vTJH2GVG0LJ03X4Y0U4kmZ6fPWI3fwxb5b2/uDdz3IC
R/T86LKKftdVtUp+Pp+bfOmYNsoyrKK//fW//wOZjb/99X/EZMZD7gxZuXvb
0J3L/QibUfBXUBRvi576R4EZbM2T6/OvTyXR8sU/mZdF3y5txx00NEtf/Mv4
J2o8pyY7a+dlvif0A4xottbCVizYEox6ouw6dYWjEnrO7PKud2i7rBzBBUf3
7fnvimk2eySrYfqRJNyw4+wQLUSSbmOWZN5pnkxetpwa4QshUTIFqOhl5TTp
Q21tt3lHPXR8k+/85853jzWSFInsW9Mj7kJfd1WB+0lTKWajqKM3q4Flyh3H
7Uj60CMdq/Qiy160vZUnery9bIuBR1ZBoNoX7ShJobC2JIE6jIR+ykLOgyV8
X9kHx2/ZteC9QXb7Br2k4wjzDi+mWDyTxox9t+usc3RnOXSeNA+zRiqDGaJo
c0fjkteUrWnaPmssRVeOpFXvqfFVTXrEibkj/VmIdm+Z8MiyzyD9ri0HdiDm
/WcV/vyQZeCgacDVPfIsaMHZgjrV77nbEGJPvaD3LS1zaqIirNi0RsH00890
mRYRQA5a2LaYB4Qve1NaslB7uj+qg05/GG9ebf+faiOpxt99Q0OqgP7Y+7am
7tC/+Ga7WpH4Cd7UIreOorV8We999I8ptmAk6e3Dkpqq+pawuWYF0g6x1HUM
yXtZV22zYVpzSKZpgewLRQgUrMV0gxfTzFSs06QupBbUIe5xh17Sq4YmPrC1
fU4mMef4Mgg50qcjZVh56DGjEbTkbizNXcsZn9LeV6SWM9E/oHVISYe5jXGq
W5DdfDAeDNIIoWGQrsgXVvgudGRpN/l91XbUrl2sFzMoXFl1JHIaSdG2O17Z
9PoHwh0kpnLXVn61IOfm3eEsUVNIEdNBiGqJ+3pbU8/6bn/sppwnNx1A0nUd
rMzHnKe6uxfOeWU7nvY4kwtxLaTnYk1odrBo1XSHdcAewNv6L/5p/sW/zNjk
z8yG7PjSkmaTlDgRUlJrZlfnPTgB1s13tMzYzFjqAil2Lut8SdLEg0fWEAvg
uDJWpAMVOUt67EGUnS6MIH06i6yn9NcWBjZaD2onVVrzsCHo4vWcA/edGue8
Jv2k9RHU5NzRfcVmbBbzslSjiZ9X1Jv2Ac1AwjzTZ1n2nzhByXolAmD9PzL4
9H1f8WMtFs1DhazPOqzxg2G7th74ZV+l70KHyEzKsFQPsagefTb77DNzvmwH
9UWTOgijMRLU5ld7KjPyVNk/6Km82/tHPZVJPFX2y57qm6Gjhjs4jhm/QiXg
xxTksgUdhnUi1rWXNW7WyMlm1J3QtYN+Uaegq/kdrYZkLBFjuFkGU4JJ4RVE
b5DmCUKZ+7yuSkESFHVuBnekm5XLtJ+inIJnVvQvEUyV1+16OktmSe8rW8sG
O8v73m53PfSvyHeMZ3ITqlcWcONv/YO3BS0gbvkyjEEMzSP4Ly+61jnFgCWc
LJtOeBGuVEnxlqvbnsbYkn2iVYq7BfjEZccQjEtoqB0yeRGelWJaRDvXXb7F
vIHPpdfG3nD0Z2LtDjw5nAD3DvEhWtgq+2nJ0njJaf8nfV2YS5lUvjVenak+
S7ApPVXdsXBvZD2o1ySDvUiDZNqkjW9sXRrGjBZOhqEEv4EkwsuYAoa3G7T6
YCENRAJz8yoxLyyNG3WLL5dwFKq17z+jVr74IJO2qjoKCBnSTzSEbFZTwktT
n6jPuvLtu8qxvSHD09u4UGppfFPtfsn4RyTg3QCvrHtatAAqFLOSk1+Ym9FK
I6i9pif4Ti8m6kSR5EQG/mVLUiL3Nq+VoxMUUrRrTL9/4wy/5uU9IE6ZYh+e
9Pu85Ae1d9T7eu8qxw+NXMsI6mOZnK9QQ0QQqUpBLzuqAtSSOpF1m9cHdjNo
b7DowcOYJ6TspXVFVy3FeL5/Lzj6wykbBFaDDstk6MYmaqZLR5DzRMtYkz4L
oXgxpjzZeh3WmWUUp+6jGjyCkkWcsOsemVGvmxym5Qw9JlDVNp/3ASCSzIAl
yHRSZFatGwiIJxvKTytJAsfGrltBCLxowrtjdnXGho3C9N7mZWid/t4BNMNN
Etiz0tqBWgQQtw/auGvRJ+jjcSnNJDAO8NOr0gxeU0KXYkPL3LL6joKXNDSh
tXh8EirHVoww2x4WEbhL2mk8FYCIBeCPgE7ejyCoIumOYTLPhXQIy1mDoVAN
Jq+C9Ru6hu8QJJGTvDysIr0i/SKISQiwwdqa+dKhebua38qLzJMf2tvTBM/P
gnRp2dAvvZbczcL05QV8Nju1rq1natHppVGnBPdu8/oBwygtmAx2in8g1aaF
NSOlAfidSI/eXFYC9ThyrRHE0+9+5lkaSWhCjoOE3PNdq6AqqItifzo7Pnu8
kv30kSKXlm8SfBbCtQZjpDvHXfQYfdsO4s+nI2DbkQNRJ/MvQxOVrV0A59BE
mrrVUEPjq/UGeI30Y0NQ4IQM4t3+xPvHviWQ6GSiSZvGagM0JFCJISVspfhb
tjQTnUEFnkZ7MAwtexrMCAFvcljbHCE8po7WEVYUgr62F42PkzObDjzEHstc
vQ/ZBwsCqUBZKHsgWtN4wHRD7Ve+GEMgVsglJz3k0BkJ9pGDWJvjDmIHKNSR
MTcnnOrxd514xxKf2yJXSRiQZrbz+qW2jBwG61ZuatCqtAj7VEngCgyK+ETM
FHBaH92ihrFQ618Vd9QgMBlSMcI5hLXk+0n2WPrR+6ggCKyoCYGUKNQkLMER
t4M6s2SWFqCWBuOcV5m0V5Ev0HcvyOVwvcWHD8ETOZmSSuAGv58c2QM7OfRF
JKRxmuiuYr8N6SaW/cBVtmL+JfirQ0fRxXwL2cFxMqVDoA4xO6khLeGBTRA/
jHiR0aI+qQ6XfGDVTGEGe1i0m6r8wlyBwMFCd4YMWg99rnCTYyxKcOZOkHd/
3Ew/tAPJWIXqO5pYJ36rKMHKshfk2fQWBlqwUugOahE6rLMCK6yaRsAAjNaW
vGGt4MP1bByZfqoET2y9Otits/W9EklCddBCHHago6lvqjaypjlikI7RssoL
XkIEV4ZCHlyxgEPXdZoJ6AHv0C8VWdam2M+UARVh0AUSF08BU3Oq0UiBBUAJ
WBU1C+twS+pUOiXzPKna+ZrDtmHrj4oEJmHYxhyR7PVNFG5nWWapRD2oPVjU
HuxB39++oS7xakn6tZKQMfaoakjGvQTKjTnvEIsUUGQQfRTWr3Hlyfn1aWh7
THwFH6dojHDvPfzfEQSaZd9xWZB7TA0r8aJVM7BBysucU3mzEb0Hd8GvOGif
Rd1qQma0QiKtEp4Rlja8i1lKTgWcYyHdVwzw8/ouLjvJ5rATfP+eU08kX7fJ
AYtpDZP9qQO/I3ZihI8hNXgy6PFQITwytLbI7EqxlNvTYtimwxuah7xJ44ww
uaCfpdvBJCdpqMqNoRabQB+4k1lgsxPhQQvGtxRsKf+HIZK4dceEGOCX+vBC
Fq9g63WuPG61pcaCkURUspDcHCn7FlQ4athLv0rJ31ZcsA22EGg11ZV0IJi3
9brDexIpKE/sFZAFjeVELpp9wAbIWeg4w0wh+VkyGFn2lpm0Yy9K1IupnBbx
JOiYCRs/E9bH9UO5p+mh0IkrjRBZrS0vqzDtzH4LmcVKBuhAWIq56tbcwTcH
rlcsmVq21I8xV+Lh9xH0lTD0qZogXq9rNv7MGg5wTbJ0/PI/yo/LAkZmw6U8
rUC8Gw0ar+TJGKOfO0deWP4OtdW8UccoRxf8XKDkkrTFelywpStE6eM4W+Pk
g2Bah4qulFBedWTGS3ASNH9P3r//6np+uai6fjXfUbfWczwwr7SNeUJRUyDK
Ck+gN+mPNt0U1Y6ARqSQSTM2HCdTpC8IdUyJyeqSiOpIUBrMVYRUJPoLpqv6
QIBKhCBxQ1q0tooJCLZ4WHw0x0jljeJ5iEj0dhTmJk0lTLtEU4V2Qde6D2hJ
nkwUQqEEPNvS3zszHGXx/XITyM2ufbfHhSXEI/aBHCw5bWx80U1ZMwH7HVuB
JBQG6vepI98h/JOwM9itUV4hoeJ7Ap7ixRhe/aUVBxtaJgn/qDHxhC9hUSYS
LzhF5GIiLV0jM2HYc8myEir39tLkwp0AW3RsCquWaS9ZydvcyTIY4P8QzPP0
85Mp3OOXzZUT3GtmxIcrM4E03pRHALry/bcClAXHeNsZTLqs7yntWTEXK9oe
mB10A9maxIWW5JVqxJeaxfFTJvkIOEaKkdasdw4wsiCUpFENTCmvGdK0l03C
utEAuhHH4HzEuAXUYyYWDyOnxbNZAOnw8gaZxUUOPXv9jnkGsnTs+tMxjXMk
X7cw0I8zRsfcQ0ovczjBvefAMTgy/5znwkOqTcyBWAxm1y1vp3wM/8SloG/V
EE8poNGMHHknFFIuMmwZZ/QeG5/YkWSUG5g5CYgwEYljqRh1kZnp3WhtefqH
IVuU5pgywYsQjpQIuZzaKIHAkoBD7Up1b30WKErQWYJGDIJZAXy8s+J+JxKp
AC33KjKPo8AccMCrdpNTvR7kN3ZV6XbdEW8XZoHTTW4oaUlGOslHtIHe2Nh6
h2Z5/Ialk3TrX4VmisZjWTEkchpvlLZwqIBELMCdqCXSFxCy1LQhCRO6DdlI
oOT64PmQ6ah8hjGZ8hqbZ163nazDENnoTQjYOUBj5kMX6GuOqICDAkkaCRce
MMFjTulPGE/c6bnzAx7P831RBlf+afJ8a2GKzYu2j6vhydXFi1OC2l+9+ubi
t1/8l3/+8MFzJHnP/MresraScjBQC4ULCyZ583XM7jvzRF4rAusBZLsdb60M
t5yytVlynWwP4wNDhvCXcKWET5hVYUuRJBvqvKv3wXSxfSInxAIVotJXEaDK
6LEsquZ3kbmB/Z8wcwm48fgkjIjVDtRLTUa+VlO3HmoGkaNXsJfznCOsUWCe
Vl0+lEPNwKJLSK4IS25IJzjVHAlbqa/gwW1VzCQRUPa1J0Gd9MxRsEFSgvgS
ddDKgwPYOsl8c7lGz2N2ZBjgvDV9ePg2kbfYi1g9FmNU5vBo7hyQiJVZvHxx
a6SaVsN+QTHbvIQpCrwn04tarEGx2jCKbJk0JL8HRAldQpugmWl1dId5LoRz
eGTdSrrrIua5aV5uItLkDNeXmuFyFLwjD/rxKa6t7STeGwMdxZ2Ip3neWGRd
WrpyMCkfmcYKqagjDtXnN32+gQZZD+XxVFfo7yxYud1A69RJ8LPVONbPK1NO
s3QAMhzbV1qRQgL6/yCtpeWDvzav9Q2nNmFs9mlJBHz7UQImy6652KEPoO6w
iAsQBkgZCfJlTuDLdsFmc9aiYv7JCQCwCahiaExur7Fia2AZ9/DmFLvadFoP
cOEsBCaiYyXqsm1THk9BgIDZezCiYlxJgUPLsTFzlOqHdJBkCvxg1PA5nW4f
PcSt9GG4IiYnEV0JZM7/9lKAvUUGPEhlOzjkcZgYBt0wbOmvNWZW152CCZd0
1EN137snNHFOiCafySAzumV1YW10SvjB3aPeh8emAaZvX4Fcy7SN3lKTpQ2q
hZdQpLsesC0PncyRUKROlL48bOiYGApSAXqPM6hgrB58MCvotWmbuQiM7n7/
Xo5e+PBBU0AxNOdFQYiA1wT9yIqwRI5EUyo2Z1AwFjkKCdxGoVs6X4FS0cmS
EBH2nPREDiyR4jTQqrasyFHYULtCcCMHrRtd3o4d2igx1Xc0tb6qx5rNgH1E
QFSWlLFMMnC4qmVuUXdnxnLjfIcq/7zO9+hWJ2gZU6k/pc95c0TdLfdNvgUs
71LOhuwM/wRiDYWE2GMGMwHtyiX28LAAByuIni4R4XDqi3UkBNMsoK4FmZac
NkFzspfE13gyRMrb/M5ybhuG18oCLjg1+MgcHUb0x7296DCF6qxZmpkobbta
+SqnXgpMTFe5O1kT1Bw1VfV+PeBdpHyjJAUJ+wHqSTOr0DlMvDfknn9Xl0bi
BeXDbJgXFcgMSYsxWc01LMFUUUBATpdmghPOhAt6Ll+dRCI+M8nQWg704By8
jhHGRKTLeuZLMwAHOVtJsS2gu+TPoKK0Mu4EUyIeOVK1MCnmwEktW5eOiPwP
x5PM2PrcCJJU0GhSfT9iSMchY+J7xEFDsWlbd7QmMJg9IS43tiINeGhClQlF
acIMCZvZEo6iWbuFFWeQuII8fYU5hx47sHVOu63pLI719ihPpFiKnA9gRWEz
BaNhcsBi5YOvR+3A8QFaIG/iu642FwEXIs6MWQu/IVQvzr2R5oicJMduhSKs
ieZ7ljrzRYpQT1+WJlGrGvb0iVBRlupVlupVgZiC+WPFArcCAkWHq678VbCA
g+WYkCDRzSn0r63yg55XTMXYcA1rjPuk7HdcY+3ja091+tQ5Yyjfj1Hy8q7R
IrhxDaB9J/F0OYYbqEEO3GaatfcRpLgTJVVG/A9XjpCGgXxzkl70qTYtJ2HV
4wQ9ptay/UecQCa3rtm7aPC2hJh4sWgpn+yXqJwSlAUZXsn2CQ3YpBXiXHJ5
IB4m58AwIjYElEDmPh0gBdat0N+th/9+lE9iwpNtreK9VcSKp2R2gPD3nK4Z
Gt4u2A+VrPzodWQiSJfmokuogdtHAXmPwS61nyBBKTZWxOqxb9zdjEjdl9Xt
ZQ1tLea4clsZE70SjT4ZNH6IQAYsoxur46khXUp0YVehSlacfhDaGWuXHFeh
GD4U4ujf6vqlXkf4RB0u+ug7VUZdldZyrTi24W4N77kd6MXXewlFc2Q3zY83
LzA3TrjvltOzyA2Ol5gU/QZLoQIJXX4ymtGkEso8STSCLnllI0PB+7mjpDWZ
xVNoTsiuVUB+7sTHJjwvqs4wHd5TqmOsgglPC/VT/v3Jzc3zU1/S7y0FM07P
h7pHKPuO3nyeeMXbYSnJQHEWP7y5vvDbw5jxeX5++8Obq1Pu+Ei7OPlz9fob
JgV8cZsruNR1po4ql2paSR3r6uX0rDqlqA6NL1sVE8w/clEfW4W0Ipd3jSk8
pJmECch747MvPHWSAA7N+WnSbFEXqigkd1hpaUCgRDRNeGi304IgZTDG6Twh
mriEYewH0ggn8JhNqViYYVIyJ5h57XMs2GX8iNAZ4W4n+2G6sXopm6i6cRQa
hN0vsbqHZrUbdkrSpGDYG/XXFzcGNN62csoYKHvKxJV0dGZ+xvk0spNldsgH
zQ5q8miKeBMMN+hdj42pzJmwIz22x3E1C4gx7+G4Uu9aazJHKddxeOzlzvoF
k8UVF+n2njbWMTOvRK6GgqpdDohcC1s3G5tdFrqLzK1XRu8PWO84+uOFEn3I
MQLluJpUzdzPXRJERVfwud99oljkR6mYmxlhWyM3OOYimsfkhAh1YMfP41fb
TIioemTXyUSNYgC4tXXVBsqP045SLgIV19yMeGloAf7vieZQnufrYMTMECDq
Nz6kmlQFcISFEvxQoAZVTWoeVJ+UMH/H3vrm6uZUGdNKE+99xeVgLOqC3kcW
Bg0VOG2o8CuSr66YQfKGJUSS4wpGWeZoAYUPib2ZIQzfVRrthQxbQNqM8Ea1
o2zBeTOPaBQjbl6XUxXRzVoz5WcTSYXsKZvSPFSJ+BoRz1Eig5An6TNuJ3gR
zUII71PFlUdyrnaguJlJ8umJUYqUq+mSOpzcJRsXtFwswRuTalBnG19oSeCg
nSsQR2RF/+6ilKqGdAW7rONuG9l9EWYp3CpclRarJvTX+/d8HMKHDwtztVgv
+CUGL0n7BHn63HDS7bwI+ETLF1vPySdzVbcFbxLjTumGEbPKccxK2pHJDcv9
OM8cszudhGpdteO0NpgfSa2NthWEgBAmaN1xDdMIc0RGAqVnVWAk4BPzjgeR
LisyFrtB8uXe8x9mD0hGq2o9aPgbvInflDgS3omfzpMwSUyahXxWbF5SpmJy
vVTHRl+URYALVqPfSiLbC1VDkwWS+rmPMB4zY/viSOYeaXSHuIElTVr6lXmp
nKZzg0DgjhnLslrxcu1jCofzQbGsft0q7cZrNt5/kERC8wHLcvPBmnjs1MR9
rYLKwjYkKICARcYaiITySUVItUVWIslxsfHrBNLFfoXNkmkHNdeJCdWtEsWm
qstO62LNBoQDXjqwCvodlKEtWJmqH0JZvrrctkkwVHoIgZNdzVrq5bw7g8Jx
5cNXWXYJeA+utYSaN74w/F72h/MeKhLUVzgRFlSBS0LWhA5R7Jc+IqzSnlmS
ElwLT0zVTDZNz/zu8jHRPg3NAwfUi+2Xv3It5RaDMGFXUUlWgcDTPee7lkS/
aWspXn3wYI9xgwsMVN3i4FxqJ+7pZLUaWY90+zTKomjpPlDEFXYe8s05mvrK
aEUfiyl4dM2HeU+zbtsynKyLt4Hw1BN2BUmkROZRasbT9yGpAylhL8feMSrn
xDkzdz7DpyhXptHLl1eJVPP2nIQuwxbkSjxy2FYeWTRw97MJn+EDCXVOVdO0
97rJkvfWojx9LuuU9/+AzWUzyxKXRQ69Fg6DyQbLhXc7Qg4d19RbTcb6gsgk
Xx5rQn0BE0VAbMilerbkvLzAhFyZBC6PkPaSoh1x+siCdUbY8cAWSTF565ez
CgSHszRcnMwOKy8Cheu1B4PDvizRBFquFocu7OXwDGBHzj0oayictgxRK4zA
yICVDfvRnYb/rNNKiNIkx3iAlNNtPDrfijvslZKPmwqdL77x/C9iQN16EhLF
sDoPoJ516R/LEr/x9kWSxL/VJLGQgsgRp8ngCWEnFk0oVD6ZQiBJ32a+1C0B
3aM4xxvkhTHnBlU6TBQj+o4wPus3kySnii5y+ZzVchy99BtejbyxRTJPVlQ8
00Do8XgleAc5AGLJCVjZTVmFrRyZq7ZDTWpmyRByRSioak6NJIbGe4vp/mQZ
YSYjVIgdRaw7O/xuPs/mjHqrLvvKITugiS1sNykkHNIjlxPYFhxRGkS93XAY
P+L+reyyrtJaEIG1Mv5wBASt7yzIvvYNl9iwoGdWf/jgp8SZk3hYtDabJYn1
Xs+PCz0/mfmXhrH4VHj01Blvsh3xwb5zJJ+v1S4eFhJq7ODD2ri7jDe1wPmo
hc88me9nk6P+vMZGq1nSNdYU6Ustqyu8LQveIi3s0SJNSWWhSpFxB+GDwJno
m1lvbOZvgRncplVaMUHJVAKwx62f6Ze+vs354/uf3L68OA1d0xKfBifRVH41
ffEb3lpOJodCPW0CMuOMUsi4VR4TbAEPQZ3SssukLgaeJfl2gO5NxOM7HAQa
WIxdEnOvOtnyXe8zZjdWAH/iMfseGwmoB/N5jG53cReI3MAOK9HGjPsk9s98
U+kmunY8nFA+aHX/JBQ4FL9lKtHQDkp85byBsLVGVEGcWDdYPT0BJYbwn0np
lnfS2BSP84YeLFZ7iC64ZkJxV960qJSKSWY2gMmvnc1iKZV0kqbqOinqFYTE
T6SH22DTUtsKk5M0wUeqSIYcBw9QFwII17Lonll2+64HGCbhJiOjN79BPNkP
qFCCkOOeC2gIf+LiYCNRlviOTa5U9k6y1TQR1TuuMXNkYTG01+o1t7yrj4v+
nZ1l0j42EMoKZkPg6wTmXLLnCtmKyy+RBoWJQR0/reUsVFppEC39KtSgeQmB
KeUu+oni6o8QRWdgm3Him9jpWGysCaxRlSp8HHK2IOW8h4I2ZhS54dAQ9I6W
g2xF3mlVVR9ME6eEGiW5G1VW0ohU2VQnxHUHp+jNlYnJRDngiaLpRk60CEXq
fNAO2CP4jiwc+mP0SzB6cJmUp9lGCrcZr8UgSsxhZNQydcPYe+YPjSEjWrbM
a+B8OK08IeCP4Fe3QiFo79otuaNFdkmhX1p9HIckSFufVA4q93ueKlFx0jpf
hIDtVN2WE2sl99uPUOJ03owwuSVL3J7W60JFKs708Jz6OHPaK/JYJ3wMSexO
8NTIy/O+HK7pBfNnXt4aTDGKAvP9iYpEDzJBQgfws0VpPuZez4mR9uLOYKlN
sNjO0McKM359FtFksbFkWUutu17lVa3bImBvOJ6lP+q2vWNv8yS1rkmIzAWh
pzoMKN3b6B+QUhHI8zxvhlXOoW1HIBN29pL9uURAt2luKHvy/M3lqeHC3H/+
z1/+5sM4deTLvAHNrOI4/4EKY8J5clninjtrYrkDL+RksclRLroVcxbmJiO9
rii8ZbDo62dDPV04Ion0fLXy++91V5fwmPRbxpV3fkeQSVsUdDOOg/ARE3Zp
deC8s8jbOsV8ODvfHD87358zQ/Or6SMZ7KZaxUJ/2X1/7KARPhvCZcyv+vCU
d3J36iDxD89G+iT0E5wDxpWpnMoRt5XR8t6BUXCnjGCQliIL7mKVhASOFka0
0EKPfXpSRcaHvWPO+Zg7SWqN3M5rzgDDpPssNVtnb77SBsisy4YADz6C/qYd
SPekJcgdWSrUbkoSM1TXVc5jNB+geQPHOmBxpBFszigJJTfa0QFYitK5H4qf
/LEarFd+xfrcI5pXZgpcdHqan1QAUCdXPU6CICFdKUWYJZQILXR19bx5wfW8
nCJLzsca8LC55zgsaLeRAyqkglhg6wknyWIem6TRrk7Mk5++v0FZvXxp4sOH
TEoF+Myi1Ofp/ivJYVLYR49B8RGY56MiFIofaVCEbIJZh2vxR28Bds3CFhXA
QuGSH3waItydhci04kAzwpRKT08Z81aB8cF2buZbuXtZHtUUP6Z9S+u2SQWW
fkLEA/HLM8nMQillDvxSOBwCp5mkIElTik4XU6wHQu2/04QUn+XAtcBkV1GW
kQOcMX8M4Spuf/3s1nyx+G1EPkMHjmPofR1XjQInwbuJUxM6Q/YwDFUtVXKA
dmh6SI/8ID0ka0CvvpB4OeMiZZ8x1/JgqWTnyph0Vz90u66YDtfuciF9tqxb
Ch1whdpNLJ5yDjIHUQ3SQiAaQNFn+q5ZTE9JNPu5S7sSNoSFwyLbDcX+6A6/
Ozuv8YL1RstP2PjgGZ9CzGt/Atl2N/TeR4Rtw3RrJhVAfdvihCw5gyw9I/VB
64PiqQSj81JI2pmGW4ytGz59RxxDOKLbzEGjHD0Y0OcrOe/pz/r2QNEv75jM
k0oUbEhGuQKpse6fhSlKK2fJmVXscVeky30ws+EN450m4fDoGI9pzibjDRS8
tr0NTHeexIARoSvh0HXF+yIYDiJ4ypCS0up59kve0M/IhJNk2PdiknxOn/Mf
8FEXOBqYwgqKYDJP9PhEkmcJ4ak/dyOGh+nihE/mr0AsO7JinCnWLtYhdGD8
8G3brms5A4kr3HWJsddKCpnEoigfzpt8mGByfJSNP7LSyxwRYB8O2sgkSSZc
ZmuYD8Vu0p+tPMUV6Zww9ntoYlnPInsZTvEUzOiXWXqgwZg5FQzDJReOD3yT
yskYQSUpCj1glCEqZ/2Qv0GZkz+AFq9SB5fJVs9046HXrfSwUT9hvo5JigRX
otzRlYeSA0EPzppHjoL0SREpi3d9FqOQUfWLhxXYkK1Kce8S1k9z+f612fv3
fMw/F7V/BpXTInhCbs8IZ2Mo6h7FjBw/NzEpIJJNlLHiPxOGJCITPqxEHQ0f
CWzTMyTE1KShI70+87vSNKtxlmVzBlso6kxy6kxWRJFpXp9RNlfPa6Ywl7xT
AkByX59k32laFGKUM3zD+l9kU2raC36rxV9JjYqMQ3WmDHsOs6RWjQ8naIrI
SEkxVa9HWUlLoxYizRiSbjGiKyv3F6lhmuuORtnlOjRSIk5t+I08eIGvRJfT
nQ4pSVqv6SmnYbq11pSBh3AT+NimbKKRMvWqS8OKbJRTBc+hta9CGKYN+PNh
7z3oDIuog/lATzi3BS6lYJIMZZnXK5rNmezADogxWTdePl6SmU9T048ot0jY
dR5THnbe40usUnM5CVCo4d9lHip6l+4NJtBMPABeEIf5g6W21bowcmCzK7bk
QPRKkyzppWUfjrMcLyAKzm29kikWsxm3HJKFQWDbdmJUfBEC00+oJ7CyWo4l
eZXwgP3LNrzn/9HUOFt+jrcmNZ6BTI8H5RDqx/Ke2gAE9eMEPDU1bJfycShQ
HGFlYS7c7+S4R588D8zYTHaEzqQ7BI3J2m6q3SxLHDV2kjBTxWeF8QHTRwUQ
FSbgncxnvpMAi2E/U33ksHDAqt/r86CBl5zL551Gsi1IrJU/xnu09Vroxp7A
Y1NCD0hs9LfmW8CFZ6EQdGzkUlNTAYawXrbi+2yCVTh6U3ifUuJSxpRkKsUe
4U3+vPHNpHo+88cjlLE3YeshKpJGa1sPPme84X2/UgyhGS4Q9gfPZEPDu9lK
f/SGrwRAR3nDp40oHQyUX482PYI4k41ZyRri4hdf8IZPZLCceO8rm6egcaF8
ktwNb3qwnJmYafo4qR+7z+vBepSuXX5kZ0JQLr9bJo24wzLgOkiNhn7nOVVZ
5dyFLOzGb3mzhvZDGpeqlFB75rd/+87EOXSCiGBm7mLhTvAsCy020AwvYf5K
jt/1eVb5yHIQ06gqWjfE+TPmYyV7EmMLUPcdDapNbytHCbSkx95NAt8xVz8+
60Kyh7Ey259doWT9QV3Q0ZLLDOc1iWPEF378PqsoUd/RZDXogUaykZ6D1ixR
Ryl890dp6/cWlnlxB8h1o6dbmxs5ePj9Z/68azmJ+AMKS2lJ2VgE61EXx6fg
87i4Ug/wauWo5D4cm+1PNFY1CgBOPo2R7mMNiYpLHNjoUENc23vMWl7kpd3y
KYZyHAp4Jz72xX8UhRnfWvfza/W5dlsP1pJeLG3NlUZae+QPoudytxh0J8IL
feBKlrBHued1Zr1GIGGnZQD96GSi9Fw9f8LX9KxpPtRan/Td3GuyP5f6NalY
eC5lLJU/4iEelZRl4w9CLWQb/P/ZN7AXKIeI205JEYBKXi34c2Zbinw2M/Pt
QK4ux0bXbwGcSFnHn+bjjvzjnwjkLjyJW0KNZ5ktCDX5PiJ6Jl9HmulHj2bJ
t4y4Ax/5aaYzc8mHNsiesoZk1zPXsOcTRlQcOOSPZ+Pil7beHz0sjOIa/xFj
7trxLyTru/DtZrwt/RD8aEDfQJuTUZHeUBNLv1WVWsky/1HOWfKpzdno85mz
I9/DnI2+cDkbf7KS+/B/+SukKgI96THL4jfw4jTHD9bN0o/QzfRrWdzNf+xL
ffr2Z1fXOtvXJQ60nXwsIdShHInGQ71nchZLlk0+2809/HUfDdeehYKSLEu+
8jtLPt07C5/jnU0+sDubfjKXu/H4F4j1lYG/zqafoJwdflFyduwjkbPRhx/5
rQdfxzxLN/3xDpRi6Ca74bRD6f43ilnix/Rm5og5DGTg2a/jAvVlylPEKeTP
z8lK2ISv2p3R3/8u38MjvSYLgiZvrm5M/CQePRAr0Vm3XjK0gkdeS8E3Clq6
Kq9xGkzZteYid7kMItEMHBuID7cWtkLJnZ6sLWm2ZJWFYwL+9td/M+fXfi83
mZxi8Cb+4vz2nCd29OXw2eRL4LMjX/aepV/rnj329W3u+q/5+PmZke+nS/fk
m+4srPhZiREUIdSS/Plh8nmJQ9RyQUq7p14gBJlhMVIvqH8y6osB5I/5znKh
BP1waaEptHxoVa2ZihoN+qojo/LjviE5kUO01ChNWIcI8ZqQA5lYMg60BAm2
0bq8u2vxb2yLfMa5zbal9mCg72C//pTT5e9BxZqXn1+2TbveIJvzPTazmLe8
MQPlqc9QiHy1puivnx18Q45+8S5m6o7HCxB/EQJpoz1I53psqeIPurRcm9zE
a+GIvhzaiSMaNFG6m7zv4Gxe593O7mdmZN6S9eCtfPD201U/g0MiodU9uvoK
Z1++RaA9dX4jt0g6SRjLmYsZqbHW5l5hRP3MjCxM6pNn+PL1xQYpCXW1R40f
XMFPFCIsK7yNGc8bRYMXHg1OVfcALW4t6ttUj9NO8Pf5ZubN7cXT69vr0+nU
62Wte4Mju7Tbtug8b/86xFSnhxOnD0PTHU386UgWehHpQ3uaClovkLeuCNWe
+gnTn/8w5A+2OmUxnIfdNRIZvj+TMj5b/teTVV47e4I1/fLyZboPZ5H9b1Jy
f4EIigAA

-->
</rfc>