<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.7 (Ruby 3.2.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-shi-quic-structured-connection-id-02" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.20.0 -->
  <front>
    <title abbrev="Structured Connection ID">Structured Connection ID Carrying Metadata</title>
    <seriesInfo name="Internet-Draft" value="draft-shi-quic-structured-connection-id-02"/>
    <author initials="H." surname="Shi" fullname="Hang Shi">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <country>China</country>
        </postal>
        <email>shihang9@huawei.com</email>
      </address>
    </author>
    <date year="2024" month="March" day="04"/>
    <area>Transport</area>
    <workgroup>QUIC</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 37?>

<t>This document describes a mechanism to carry the metadata in the QUIC connection ID so that the intermediary can perform optimization.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://VMatrix1900.github.io/draft-quic-structured-connection-id/draft-shi-quic-structured-connection-id.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-shi-quic-structured-connection-id/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/VMatrix1900/draft-quic-structured-connection-id"/>.</t>
    </note>
  </front>
  <middle>
    <?line 41?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>Nowadays, media applications are usually able to dynamically adjust the size and quality of the stream to adapt to fluctuating network conditions. However, for the high throughput and low latency media traffic, adaptation only by the endpoint is not good enough, especially when the network condition is challenging, such as the wireless networks discussed in <xref target="I-D.kaippallimalil-tsvwg-media-hdr-wireless"/> and <xref target="I-D.defoy-moq-relay-network-handling"/>. To this end, it is desirable to have the intermediary performing optimization for the endpoint. For example, low-priority packets can be dropped to save the resource when the network is congested.</t>
      <t>One example of such an intermediary is the relay in the Media over QUIC working group. To quote the charter from the MoQ working group. "Media over QUIC (moq) will develop a simple low-latency media delivery solution for ingest and distribution of media. This solution addresses use cases including live streaming, gaming, and media conferencing and will scale efficiently." "Even when media content is end-to-end encrypted, the relays can access metadata needed for caching (such as timestamp), making media forwarding decisions (such as drop or delay under congestion), and so on."</t>
      <t>Due to the end-to-end encryption of the QUIC, the intermediary does not have the necessary metadata to perform optimization. A similar problem exists when the media is encrypted and transferred using SRTP <xref target="RFC3711"/>. To solve the problem, <xref target="I-D.ietf-avtext-framemarking"/> defines an extension of the RTP header containing the video frame information. This document defines an extension of the QUIC header, using the connection ID to carry the necessary metadata. To mitigate the linkability between the multiple connection IDs of the same connection and protect privacy, the metadata <bcp14>MAY</bcp14> be encrypted and only decrypted by an authenticated intermediary. Similar to <xref target="I-D.ietf-quic-load-balancers"/>, a configuration agent is used to distribute the encryption parameters and the template of the metadata.</t>
    </section>
    <section anchor="terminology">
      <name>Terminology</name>
      <t>This document uses terms in the <xref target="I-D.ietf-quic-load-balancers"/>:</t>
      <ul spacing="normal">
        <li>
          <t>"client" and "server" refer to the QUIC endpoint.</t>
        </li>
        <li>
          <t>Intermediary refers to a network element that forwards QUIC packets and does not possess the QUIC connection keys. Such an intermediary can be QUIC proxy defined in the MASQUE working group, wireless node described in the <xref target="I-D.kaippallimalil-tsvwg-media-hdr-wireless"/>, and relay defined in the Media over QUIC working group.</t>
        </li>
        <li>
          <t>CID: Connection ID in the QUIC header.</t>
        </li>
        <li>
          <t>Configuration agent: An entity that distributes the encryption parameter and the template of the metadata field.</t>
        </li>
      </ul>
      <t>All wire formats will be depicted using the notation defined in <xref section="1.3" sectionFormat="of" target="RFC9000"/>.</t>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <?line -18?>

</section>
    </section>
    <section anchor="architecture">
      <name>Architecture</name>
      <figure anchor="arch">
        <name>Architecture of the intermediary</name>
        <artwork><![CDATA[
                             + --------------+
                             | Configuration |
         +-------------------+     agent     +-------------------+
        /                    +------+--------+                    \
       /Config Parameters and template of the Metadata field in CID\
      /                             |                               \
     /          _______             |              _______           \
+---V----+     (       )     +------v-------+     (       )     +-----v----+
| Client +----( Network )----+ Intermediary +----( Network )----+  Server  |
+--------+     (_______)     +--------------+     (_______)     +----------+

]]></artwork>
      </figure>
      <t><xref target="arch"/> shows the architecture of the optimization intermediary. The sender, which can be either the client or server based on the direction of communication, incorporates metadata into the connection ID field as outlined in the referenced section (See <xref target="format"/>). This metadata allows the intermediary to execute optimizations tailored to the information provided. Given that various applications may require the disclosure of distinct metadata to the intermediary, a standardized template is adopted to specify the metadata's content and structure. There are two primary methods for obtaining this template:</t>
      <ol spacing="normal" type="1"><li>
          <t>For each category of application, a specific template is crafted and cataloged within a new IANA registry. This approach leverages the global accessibility of the template definition, eliminating the need for its distribution by the configuration agent. The responsibility for developing these templates falls to the respective working groups or documents, which is beyond the scope of this document.</t>
        </li>
        <li>
          <t>The configuration agent, operating within its domain, defines and disseminates the template. This strategy ensures the template's relevance and effectiveness is confined to the domain under the agent's control, tailored according to the capabilities of the network devices present.</t>
        </li>
      </ol>
      <t>If the network between the intermediary and endpoints is not trusted, the metadata <bcp14>MUST</bcp14> be encrypted. In such scenarios, the encryption parameters must be exclusively shared with authenticated intermediaries, potentially via the configuration agent. A viable encryption strategy might involve adopting the algorithm proposed in <xref target="I-D.ietf-quic-load-balancers"/>, ensuring the security of the metadata.</t>
    </section>
    <section anchor="format">
      <name>Structured Connection ID</name>
      <figure anchor="cid-format">
        <name>Format of structured CID</name>
        <artwork><![CDATA[
Structured Connection ID {
  Config Parameters (8),
  Metadata (40...152),
}
]]></artwork>
      </figure>
      <t>The format of the structured connection ID is shown in <xref target="cid-format"/>. The content and the format of the metadata field are defined by a template, carrying the information such as media characteristics in <xref section="3.1" sectionFormat="of" target="I-D.ietf-avtext-framemarking"/>, the service requirement such as delay and importance in <xref section="3" sectionFormat="of" target="I-D.kaippallimalil-tsvwg-media-hdr-wireless-04"/>.</t>
    </section>
    <section anchor="coexistence-with-quic-load-balancer">
      <name>Coexistence with QUIC Load Balancer</name>
      <t>As both the Metadata and Server ID share the same field within the Connection ID (CID), it's crucial to devise mechanisms that prevent conflicts and ensure their seamless coexistence.</t>
      <t>If an intermediary serves dual roles as both the load balancer and the optimization node, and if both entities are underpinned by a unified trust relationship, then it is feasible to consolidate the Metadata and the Server ID specified in <xref target="I-D.ietf-quic-load-balancers"/>. This consolidation allows for the utilization of a singular Config Parameter and a shared encryption/decryption methodology.</t>
      <t>Conversely, if the load balancer and the optimization node are separated, the Server ID and the Metadata needs to be segregated too. One option is to split the CID into two segments: one for the Server ID and the other for the metadata. Each segment would be governed by its own set of Config Parameters and subjected to individual encryption protocols, ensuring the integrity and segregation of the transmitted information.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>TBD</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC3711">
          <front>
            <title>The Secure Real-time Transport Protocol (SRTP)</title>
            <author fullname="M. Baugher" initials="M." surname="Baugher"/>
            <author fullname="D. McGrew" initials="D." surname="McGrew"/>
            <author fullname="M. Naslund" initials="M." surname="Naslund"/>
            <author fullname="E. Carrara" initials="E." surname="Carrara"/>
            <author fullname="K. Norrman" initials="K." surname="Norrman"/>
            <date month="March" year="2004"/>
            <abstract>
              <t>This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3711"/>
          <seriesInfo name="DOI" value="10.17487/RFC3711"/>
        </reference>
        <reference anchor="RFC9000">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <date month="May" year="2021"/>
            <abstract>
              <t>This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9000"/>
          <seriesInfo name="DOI" value="10.17487/RFC9000"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <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">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <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 anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="I-D.kaippallimalil-tsvwg-media-hdr-wireless">
          <front>
            <title>Media Handling Considerations for Wireless Networks</title>
            <author fullname="John Kaippallimalil" initials="J." surname="Kaippallimalil">
              <organization>Futurewei</organization>
            </author>
            <author fullname="Sri Gundavelli" initials="S." surname="Gundavelli">
              <organization>Cisco</organization>
            </author>
            <author fullname="Spencer Dawkins" initials="S." surname="Dawkins">
              <organization>Tencent America LLC</organization>
            </author>
            <date day="14" month="February" year="2024"/>
            <abstract>
              <t>   Wireless networks like 5G cellular or Wi-Fi experience significant
   variations in link capacity over short intervals due to wireless
   channel conditions, interference, or the end-user's movement.  These
   variations in capacity take place in the order of hundreds of
   milliseconds and is much too fast for end-to-end congestion signaling
   by itself to convey the changes for an application to adapt.  Media
   applications on the other hand demand both high throughput and low
   latency, and may adjust the size and quality of a stream to network
   bandwidth available or dynamic change in content coded.  However,
   catering to such media flows over a radio link with rapid changes in
   capacity requires the buffers and congestion to be managed carefully.
   Wireless networks need additional information to manage radio
   resources optimally to maximize network utilization and application
   performance.  This draft provides requirements on metadata about the
   media transported, its scalability, privacy, and other related
   considerations.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-kaippallimalil-tsvwg-media-hdr-wireless-04"/>
        </reference>
        <reference anchor="I-D.defoy-moq-relay-network-handling">
          <front>
            <title>MOQ Relays for Support of High-Throughput Low-Latency Traffic</title>
            <author fullname="Xavier de Foy" initials="X." surname="de Foy">
              <organization>InterDigital</organization>
            </author>
            <author fullname="Renan Krishna" initials="R." surname="Krishna">
              <organization>InterDigital</organization>
            </author>
            <date day="23" month="January" year="2023"/>
            <abstract>
              <t>   This document describes a mechanism to convey information about media
   frames.  The information is used for specific handling in functions
   such as error recovery and congestion handling.  These functions can
   be critical to improve energy efficiency and network capacity in some
   (especially wireless) networks.  Due to end-to-end encryption, MOQ
   relays are expected to extract the metadata required by these
   functions.  This document aims to enable a level of wireless network
   support for MOQ equivalent to what is possible for RTP.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-defoy-moq-relay-network-handling-01"/>
        </reference>
        <reference anchor="I-D.ietf-avtext-framemarking">
          <front>
            <title>Video Frame Marking RTP Header Extension</title>
            <author fullname="Mo Zanaty" initials="M." surname="Zanaty">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Espen Berger" initials="E." surname="Berger">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Suhas Nandakumar" initials="S." surname="Nandakumar">
              <organization>Cisco Systems</organization>
            </author>
            <date day="26" month="July" year="2023"/>
            <abstract>
              <t>   This document describes a Video Frame Marking RTP header extension
   used to convey information about video frames that is critical for
   error recovery and packet forwarding in RTP middleboxes or network
   nodes.  It is most useful when media is encrypted, and essential when
   the middlebox or node has no access to the media decryption keys.  It
   is also useful for codec-agnostic processing of encrypted or
   unencrypted media, while it also supports extensions for codec-
   specific information.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-avtext-framemarking-15"/>
        </reference>
        <reference anchor="I-D.ietf-quic-load-balancers">
          <front>
            <title>QUIC-LB: Generating Routable QUIC Connection IDs</title>
            <author fullname="Martin Duke" initials="M." surname="Duke">
              <organization>Google</organization>
            </author>
            <author fullname="Nick Banks" initials="N." surname="Banks">
              <organization>Microsoft</organization>
            </author>
            <author fullname="Christian Huitema" initials="C." surname="Huitema">
              <organization>Private Octopus Inc.</organization>
            </author>
            <date day="5" month="February" year="2024"/>
            <abstract>
              <t>   QUIC address migration allows clients to change their IP address
   while maintaining connection state.  To reduce the ability of an
   observer to link two IP addresses, clients and servers use new
   connection IDs when they communicate via different client addresses.
   This poses a problem for traditional "layer-4" load balancers that
   route packets via the IP address and port 4-tuple.  This
   specification provides a standardized means of securely encoding
   routing information in the server's connection IDs so that a properly
   configured load balancer can route packets with migrated addresses
   correctly.  As it proposes a structured connection ID format, it also
   provides a means of connection IDs self-encoding their length to aid
   some hardware offloads.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-quic-load-balancers-19"/>
        </reference>
        <reference anchor="I-D.kaippallimalil-tsvwg-media-hdr-wireless-04">
          <front>
            <title>Media Handling Considerations for Wireless Networks</title>
            <author fullname="John Kaippallimalil" initials="J." surname="Kaippallimalil">
              <organization>Futurewei</organization>
            </author>
            <author fullname="Sri Gundavelli" initials="S." surname="Gundavelli">
              <organization>Cisco</organization>
            </author>
            <author fullname="Spencer Dawkins" initials="S." surname="Dawkins">
              <organization>Tencent America LLC</organization>
            </author>
            <date day="14" month="February" year="2024"/>
            <abstract>
              <t>   Wireless networks like 5G cellular or Wi-Fi experience significant
   variations in link capacity over short intervals due to wireless
   channel conditions, interference, or the end-user's movement.  These
   variations in capacity take place in the order of hundreds of
   milliseconds and is much too fast for end-to-end congestion signaling
   by itself to convey the changes for an application to adapt.  Media
   applications on the other hand demand both high throughput and low
   latency, and may adjust the size and quality of a stream to network
   bandwidth available or dynamic change in content coded.  However,
   catering to such media flows over a radio link with rapid changes in
   capacity requires the buffers and congestion to be managed carefully.
   Wireless networks need additional information to manage radio
   resources optimally to maximize network utilization and application
   performance.  This draft provides requirements on metadata about the
   media transported, its scalability, privacy, and other related
   considerations.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-kaippallimalil-tsvwg-media-hdr-wireless-04"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA5VZ63LcthX+z6dA1z8q1cuVZbuTRJMmlSU71oxlO5acTqbp
dLAkdomYJGgA3PVaUZ6lz9In63cOQC65usTdH9IuCByc63cuTNM08dqX6khM
LrxtM99alYsTU9cq89rU4uxUnEhrN7peinPlZS69nCRyPrdqdc+hSZJJr5bG
bo6E83mS5CarZYV7cisXPnWFTj+2OktdTyDNegKpztNHjxPXzivtHBb8psHR
s+eXL4R4IGTpDO7Wda4ahT+1n0zF5Oz4Gf4Zi2/vLl9Mkrqt5soeJeBYHSUg
7lTtWnckcKNKwPyTRFolQejSyto1xvpJsjb2w9KatsHyj+/PTibJB7XBYn6U
iFSc1V7ZWvn0lIRIVqpuQVqI8QkhAruTf4AY6e0Hekzr0mYF1gvvG3d0cFBJ
XdKSXqmZVn4xM3Z5QAsHc2vWTh2Qhg7o4FL7op3j6E/n0lv96fCbR48Ogibv
1SKdLSG/84NrBzRmgfBMmy+hdvCFtpsVvionSSJbXxhLChIp/RFC19D/y5m4
KHRYCD7xUkJL/Rq0IGv9WRI1PGvlWmlxqbKiNqVZauXCNkXqg3cVusDxb/5e
8MZZZqrwPDNt7cn/TgpdyySpja1AcwWLJbpeDH7NZrMkSdNUyDlEkplPkstC
OwGfbSt4l8iVy6yeKyekqMAI2HOV8EZkFBrCFwrLITYgIv8mVxDZKI6cwRPp
+bEmT6pUriXOZ7IWjbLEkjCN11UUPnJV6TwvVZI8IP+zJm+ZYpK8NmtcuXFT
wYSEbJpSZ3wSjFolWtfKstxArFIRt/kG6sYOXst/bV3gxenPSsg6Fx+xXfuN
MIuw7hEeLCauaTx9WZRkcFwBeyEOKFpIyFzzpTPx0qzVStmpgCxMo9DLAl8Q
AMuiaT1fU5o1O2WdbSLnUPpiobNpuIglEKYGl/OgXAR5Y6AyAaPUxoulMTkW
iehUKNeoTLNQ60IF7d/gjU7CbmWp6iWYnwrXZoWQjnevtVWlcq47Bstrl7XO
AdVgzqur78/S09kHqZsGFHQFLZWpd6v1MmX+0yK3aUfk+pqFjIdytTCbtDIf
UzyVmzTekMKF8hKMXF/PxCX5BfiDlFOhWUg4nLad2Qq5UjedJjoMWWLoM73m
O53NxAusqE+yako1JeWnjdXGkqEbmX1Q3rEDzhWg2TQNZMadrrvTKmdam6mb
uiWNmnoJbFE5PPVNrbpbyIGCfusxz9pFmlBFFyjn7AEGXhNiZh1BkzGVlfOx
NT4wAwtakBMLa6pw2Py4e2CyS3AP2t+HjcsSal2p0jSIYqeZUdLG2BVzVQIU
wKszZdsrVLOcbFi4BtBzHp5BUD4GPsmC/RmZ51CcA2C0DmxL+qbrrGxz4pRu
iNHFvriM/4l84AKKXSgLtmg7LTP7DqELJVOoaMBSuZlNxOQ5slAwTn/UqxAq
cIHUmxT/8DWzmwaWmm4tEOwus4xcv8evWqkcPkBSZxK5CQzs9cGiK6gBNt4H
5kjWergUu9fSsnA5gtExBPXHyK8oMeds9xYZ23aug437QXCgIxAPWeO0Za+P
PrwjQFR6h7DTm3GRGxVAog8bQDAkpGe9kKB/K+CKY/IMysqisQbxV8GnYXC3
df8gMGs3qpTZ91RDwGZUCbWOFHHx7vItYOBP716cPPnq8DBGOlwkshUvmHZQ
QRVAKldeffLpwiIvVpIdG4ACFNE1ZZ8a7MC6bqAGuqVQMurUS13T5fRkpXMF
yCZSok94JORucrubOAdQoD6NYnEcjvLaKA/eVDaLXQGFlzKGMYDvg5xrzjVz
oInqVNuWXlNYjui7Ph+RIINHpHYo0eMn/uuVzDbTcS4+P/6ZcG1sKU4s8NK4
hBRDUYBSBcqg9Mmgv3UoFCvRIyDn0FRcApVG5ulclrLOlAX2w5c5ePWytQGP
5TJGY+sCtPYAoqKP947dSLIVrnbBpfDUK+AU6S3qoFcqlQOXivCfiqLNbsXS
EuKQEK7D2T9kHYVQKiZZSdAyYQYmTllg4QRwAc/ugpJ9os8uSayKu/DjrY6L
hj5TIC8yU1z9RKhwgU6XgRhZu8htDEGnu7WOQjmOOuPituwSs1iga82nTXTt
vE81xxc/vn8+ThjTQfY3uepLvXxHb1+c/QOahRS3e/+9qQ6aPDk7Pdppvobl
ZAhE3njTxY7EMQIYLuw3QdFbP3N3Otof+plYaFVSej9G/iEhRcARFzISFQ2q
0ZnvUY8xwMQabiD/1dVFFOpw9oRuIVxEB/IIuAhffiDeKXilZUdx4hUq+hZi
kVsrsjnpCj4zOX9/cUnNHv0Xr9/w93fPoZ13z0/p+8XL41ev+i9J3HHx8s37
V6fbb9uTJ2/Oz5+/Pg2HsSpGS8kECDIJFp28eXt59ub18atJsMkw2qjYhsfP
YypqrGKwccnIm56dvP3vfw6fxpzw+PDwG0B7+PH14VdP8YOSzHQLUuEnNLpJ
UNsrSXUImt8Snt5ojy54StnVFWZdwzesgiL/8k/SzL+OxLfzrDl8+l1cIIFH
i53ORouss5srNw4HJd6ydMs1vTZH6zuaHvN7/PPod6f3weK33yOFKJEefv39
dwkh4TF10ZQI0Iwmye+//x5awLs+D0U6+jy8f/tvO/H223b7w/Tm5yE/Cbh/
556exMGtDMZdY5I7n186GgeBPfF2J3/sxPT5KKbJl4A3HZFb2Rho4P5PpDIg
8u/wuY/KzS2/JCTxT1uJ9+KDff4b1bEaKeW2LaugYtiNs1lY3ROvYz7aD6dH
eev2LeKCMyBYT3ZssRe5H3H2hVseBhe9OhIPaNojeAL3t8nQiTubDRPc5DpJ
rq7oBKCCoj7gurzl2KgjHFczBKiOpmao6NaFxvUxbyqNk6F3DEUAleyhAhBz
ScWLCbkoB0xnXSWemapq6zh2mFKTY2xjLM2chjORWDuMC8fgh4Aw0/pymCi5
iEC+woqL2/cuFOXikH2ur/djFdtfAVjsFDIqCnCx+qQyqraGSsFOqUtjQ0kW
TvUVMlUPVDznM/GDXnFxiny6kmibWzces1SSSh7OXFE3LiuNi6agFAyN+FHj
scsilYxoquqcGqjPahC3kE/mhqtUaslpzLEYT5v+7Pp+j3uobiDHZrYqJKa1
ofK4ijV5YZBHqbsz822zQI15vBVl4GGcGUh2jjDGJXEGkjPTzJDORgxnNCKM
lTa2ShSnitpX3FFzSbgWZ8evj6G0JdUnm2hHkLaG7itpfgTsDKZclgYVauxR
dWwZoo/3t3KVoQNX6N5REocBVWhHYi+rvRu37nG0dEuxHmIE/XsDC3eXLrh/
5fFBpO22LECh8D/XWdfySIqGi+MSz3ETHIsG14UfpJ+rjYmFmMtME8N4UGHM
kseBq1vYncKxlQ0iRz2zsKaCeaeD9o5nF06xfqJ+OwG6+YWnwF1uBE3K7c4e
+BrVuCvqF5iaWiyClDVVz2EcFOq9qIfAQmz4GaqI3+iz1pTTbRDCwibMDzqk
kE1oEbXqG8Cun4AdNBwCXg0jkHKSs/GGYVM5QgNmO7YurpsmImhcPxnZ9o5U
Ng2bxxkSRhhruUzVBAZuek8HV9F4lc5/ykqUxvCcDUBb2hgNd3ecEHiKFoiC
Okw1VzQhvctVj+kxDQoHXPRmrPSyQO9Zr3jowFjSBYYslzQDLCoCOzRco1Hn
ff0tu0ZHBejc2kFMjtrTO18oXT2IMM5p8O5tKCpuVjZ7X+9P8aAvZvaePprN
Zod/fYzl6z6vZjpPwyVddn0RftFocnDh2SllVYqsRf88zr67PeOcpbuCm7W1
vYbHO8FIPRz7G2THbRXDc9cj0Ryij7VpmKh0ah7mpm6oFqd98CiJ9stSpsnc
uNN6Mjuki/9gujSNlrQUVF0y47amn99xM0sS6YpekzECjG/q7/nCPjl99DQ0
frAwT9go24fA4Fb3FfxOPIt+h+4TGGl8MS5jiaFYn9HblULGHMxzoqDgiIe0
OvatPVh+n6bthEYwNSKNZzNAFqe273hcSP0AmhUphCIQGTDOKwJIEnFNhZKs
eIqQbeUJwLQ7puCSCkptcSVAkKB5IB0FnOgCrveiUT1Hc4rQJepFOMhtPwEl
v/UhuEWS6p0K5Rm0kQec48kE1y6Fbtj0dXznsFAS2S68cqC3pabUeTexG+mc
FgZ6D1XAF+JHTDRb+gxloXbr3lwgP5edrFR1CBostDSB20UDZkd2sLpFwIM4
3iMKoeThIRnsAQrg2wGMp6S9/0PjrFunCOH7ZLHVQnfsfDhGd3Eo4NQS5Y4M
dZyZCXpVYprutRSXdkh0wUt55EM5EFUbznGlcITKW/XquXmp4cK9e76duz6n
gioSQSXSIiDAzZIGUNE5qFAgMHOKIer2PtK1819VFqtQXecatTE57zDvWeNN
ZmgiMcoP5PhLThBMKOphMGDmsXmlfciB2xk1548uuZxQHZarkPgc4PrZafI/
ipvFf7ogAAA=

-->

</rfc>
