<?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.39 (Ruby 3.2.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-shi-quic-structured-connection-id-01" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.18.0 -->
  <front>
    <title abbrev="Structured Connection ID">Structured Connection ID Carrying Metadata</title>
    <seriesInfo name="Internet-Draft" value="draft-shi-quic-structured-connection-id-01"/>
    <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="2023" month="September" day="12"/>
    <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>"client" and "server" refer to the QUIC endpoint.</li>
        <li>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.</li>
        <li>CID: Connection ID in the QUIC header.</li>
        <li>Configuration agent: An entity that distributes the encryption parameter and the template of the metadata field.</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 endpoint encodes the metadata into the connection ID field (See <xref target="format"/>). The intermediary performs the related optimization based on the metadata. Since different applications may need to expose different metadata to the intermediary, a template is used to define the content and the format of metadata. The template is determined and distributed by a configuration agent. If the network between the intermediary and endpoints is not trusted by endpoints, the metadata <bcp14>MAY</bcp14> be encrypted. In this case, the parameter for encryption <bcp14>MUST</bcp14> be shared only with the authenticated intermediary through the configuration agent. The means of authentication and the distribution of these parameters and template is not in the scope of this document.</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="5" sectionFormat="of" target="I-D.kaippallimalil-tsvwg-media-hdr-wireless-01"/>.</t>
      <t>If an intermediary acts as both the load balancer and the optimization point and they share the same trust relationship, the Metadata and the Server ID defined in <xref target="I-D.ietf-quic-load-balancers"/> can be put together and share the same Config Parameter. Otherwise, if a QUIC connection goes through both the load balancer and optimization point, an additional mechanism is needed for the coexistence of the metadata and the Server ID. The details will be worked out in the later version.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>TBD</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <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>
        <name>Informative References</name>
        <reference anchor="I-D.kaippallimalil-tsvwg-media-hdr-wireless">
          <front>
            <title>Media Header Extensions 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</organization>
            </author>
            <date day="5" month="July" year="2023"/>
            <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 are able to dynamically adjust the size and quality of a
   stream to match available network bandwidth.  However, catering to
   such media flows over a radio link where the capacity changes rapidly
   requires the buffers and QoS in general to be managed carefully.
   This draft proposes to provide metadata about the media transported
   in each packet to allow the wireless network to manage radio
   resources optimally and to maximize network utilization while also
   improving application performance.

   This draft discusses at a high level potential solution options to
   this problem and the trade-offs involved.  The draft then defines a
   solution that uses a new UDP option to carry media metadata between a
   UDP source and destination.  This option is compact and has low
   processing overhead at the wireless router.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-kaippallimalil-tsvwg-media-hdr-wireless-02"/>
        </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="15" month="August" year="2023"/>
            <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-17"/>
        </reference>
        <reference anchor="I-D.kaippallimalil-tsvwg-media-hdr-wireless-01">
          <front>
            <title>Media Header Extensions 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>
            <date day="20" month="February" year="2023"/>
            <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 are able to dynamically adjust the size and quality of a
   stream to match available network bandwidth.  However, catering to
   such media flows over a radio link where the capacity changes rapidly
   requires the buffers and QoS in general to be managed carefully.
   This draft proposes additional information about the media
   transported in each packet to manage the buffers and optimize the
   scheduling of radio resources.  The set of information proposed here
   includes importance of the packet, burst length and time budget to be
   conveyed by the media application in a new UDP option.  The metadata
   in the UDP option is used to provide the wireless network the
   flexibility to prioritize packets that are essential when the radio
   capacity is temporarily low, defer packets that can tolerate some
   additional delay, or even drop packets selectively in more extreme
   conditions.

   This draft defines media metadata, a new UDP option to carry this
   metadata and the operational aspects for using it between a UDP
   source and a on-path wireless entity.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-kaippallimalil-tsvwg-media-hdr-wireless-01"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA41Y7XLbNhb9z6fAMn/sjShHTTpNPN1mXdvZeCaOE1vpTme7
swORkIiGJBgAlKK6zrPss+yT7bkASJGS7EQ/bAkELu4999wvJkkSWWkLcczi
G6ub1DZaZOxUVZVIrVQVuzhjp1zrtawW7FJYnnHL44jPZlosHzgURym3YqH0
+pgZm0VRptKKl7gn03xuE5PL5FMj08R0ApK0E5DILHkyiUwzK6UxWLDrGkcv
zqevGHvEeGEU7pZVJmqBP5WNRyy+OPkZ/5TGt+vpqziqmnIm9HEEjcVxBOFG
VKYxxww3igjKP424FhyCpppXplbaxtFK6Y8LrZoay+8/XJzG0UexxmJ2HLGE
XVRW6ErY5IyMiJaiaiCaseEJxry68T8hjHD7Bz2mda7THOu5tbU5PjoquSxo
SS7FWAo7Hyu9OKKFo5lWKyOOCKEjOriQNm9mOPrLJbdafp68ePLkyCP5IIp0
toD9xvau7ckYe8Fjqb5F2tE3+m6c27KIo4g3NleaAGIJ/WFMVsD/9Zjd5NIv
eE685kCpWwMKvJJ/cJKGZw1fCcmmIs0rVaiFFMZvEwQf2JXLHMdf/D13G8ep
Kv3zVDWVJf6d5rLiUVQpXULmEh6LZDXv/RqPx1GUJAnjM5jEUxtF01waBs42
JdjFMmFSLWfCMM5KKAL1TMmsYimFBrO5wLKPDZjofhMVWDqII6PwhFv3WBKT
SpFJjvMpr1gtNKnEVG1lGYwPWpUyywoRRY+If1pljZMYRW/VCleuzYg5QYzX
dSFTdxKKasEa0/CiWMOsQpC22RpwY4dby35vjNfFyD8E41XGPmG7tGum5n7d
IjycmbimtvRlXpDDcQX8hTigaCEjM+kuHbPXaiWWQo8YbHEycrnI8QUBsMjr
xrprCrVypKzSddAcoM/nMh35i5wFTFXQcubBRZDXCpAxOKVSli2UyrBIQkdM
mFqk0hm1yoVHf0c3Ogm/FYWoFlB+xEyT5owbt3sltSiEMe0xeF6atDEGWQ3u
vL19eZGcjT9yWdeQIEugVCTWLFeLxOmf5JlOWiF3d87IcCgTc7VOSvUpwVO+
TsINCSiUFVDk7m7MpsQL6AcrR0w6I0E4qVu35XwpdkkTCEOe6HOmQ77FbMxe
YUV85mVdiBGBn9RaKk2Ornn6UVjjCDgTSM2qrmEz7jTtnVoY1ehU7GJLiKpq
gdwiMjD1qhLtLUQgj2811FmaIBNQtIFy6RigwBofM6uQNF1OdeB8apT1ysCD
GuLYXKvSH1bvtw/E2wIPgP4hfFwUgHUpClUjio10ihIaQypmokBSgK5GFU0H
qHR2OseCGsieM/8Mhrpj0JM82J3hWQbgDBJGY6A2p2+ySosmI03phhBdjouL
8J/Eey0A7FxoqEXbadmpbxC6AJlCRSItFetxzOJzVCHvnO6oFT5UQIHEqgT/
8DXV6xqeGm084P3O05So3+WvSogMHCCrU47aBAUOumCRJWCAjw+Rc7hD3V+K
3SuunXEZgtG4FNQdI15RYc6c3xtUbN1SBxsPveHIjsh4qBpnjWN94PCWAQH0
NsOOduMiU8IniS5skIJhIT3rjIT8vQmXnRAzqCqzWivEXwlOw+FmQ39vsEM3
QOrUt9RDwGfUCTWGgLi5nr5DGvjL9avTpz9MJiHSQZGgVrhg1KYK6gASvrTi
s03mGnWx5I7YSCjIIrKi6lNBHXjX9GCgW3LBA6aWy4oupydLmQmkbBLFuoJH
Rm4Xt/uFuwDy0kfBLBeHg7o2qIO7YDuzS2ThBQ9hjMT3kc+kqzUzZBPRQtsU
VlJYDuSbrh6RIb1HBDtAtPiJ/3LJ0/VoWIsvT36lvDb0lCssYGlYQomhKECr
AjCofLqkvyEUmpXACNjZd5VrgQrFs2TGC16lQiP3g8sueOWi0T4f80WIxsb4
1NolEBE43hG75uQrXG08pfDUCuQpwi1g0IFK7cBUUP6npmi93bE0lHHICNPm
2a+qjkYoYXFaUGqJnQKxERq5MEa6ALPboHSc6KpLFLriNvzcVuOahq5SoC46
pVz3E1KF8XLaCuQyaxu5taLUafb2UWjH0Wfc7KsuoYp5uVp9XgdqZ12pObl5
/+F8WDBGveqvMtG1etkWbt9c/X028yVu+/4HSx2QPL04O94avvrtpA9Et3GX
YsfsBAEMCtu1B3rDM3Mv0b7KMzaXoqDyfoL6Q0Yyn0eMr0jUNIhaprbLei4H
qNDD9ey/vb0JRk3GT+kWyouYQJ4gL4LLj9i1ACu1I4phb9DRNzCLaC3I54QV
OBNffriZ0rBH/9nbK/f9+hzoXJ+f0feb1ydv3nRforDj5vXVhzdnm2+bk6dX
l5fnb8/8YayywVIUI4PE3qPx1bvpxdXbkzex90k/2qjZBuNnoRTVWrhkY6IB
m34+ffe//06ehZrw3WTyAqnd/3g++eEZflCRGW2SlP8JRNcRenvBqQ/B8FuA
6bW0mIJHVF1NrlYVuKEFgPzrvwiZfx+zH2dpPXn2U1gggweLLWaDRYfZ7srO
YQ/inqU913RoDta3kB7qe/Lr4HeLe2/xx5coIYIlk+cvf4ooE57QFE2FAMNo
FH358sWPgPd9HrNk8Hn88PY/t+Ltz832x8nu57F74vP+vXs6EUd7FQy7hiK3
Pr+1Mo68euzdVv3YiunLQUwTl5BvWiF71egh8PAnSOkJ+Y//PCRld8tvEVn8
y8big/Dg0P0NcCwHoOzbsvQQw2+umvnVA/Y21KNDf3pQt/ZvYTeuAkL1aMsX
B0H7gWbfuOWxp+jtMXtEb3uYewP3t7hP4tZn/QIX30XR7S2dQKqgqPd5ne85
NpgIh90MJVQjXA/ejdUoDah9ZvtFRij4w27Pk+fgRlBp9MXg7u7Qy903oG5G
PsqJA8VmnFoiVQ07G/Rb6EhQvuZuBLLD9xolyiqNKJRvxWd0Cv2d/f5+Gz3q
zLqI6Ldjrka1hrrRqS2K3jo/5HW9bL9Yukndui4sNJebous7y33N4JhdzAeT
dL8HHkDI3eDjnWTalx9WNyaI7559pe/FjaFk0SjqN296ABr1es2Bqxc4bTBs
i7YSSZt7st3bJ7dveVokd62eOhUxJhGiPUFtL08Ht6drrBmx0xj38CdEQo9k
UlWHCOgVZ9cp3/tu+/ZRoLCLyPu3Ib/tJtmD54cjPOjy6sGzJ+PxePL9d1i+
60I8lVkSmBQC/VXHK9O78OKMAnw64F14DdfuGUaibGu/a68217hJ80E673Z4
roVp2zVH3BbkkR/u2t6uN0h279DCiwfwhaMT1HChTM2w6Xs6ntDFXxl0PTNp
6pAp5YyuI+yu8q8QyCJZ0ht7Gl6GN33f3fONLXvyZOJ6UATl9kQBcwzdOlOB
/jQzsXZm6oAdJDWfUcOjtY+izfjqgtdnQ0pnuaxHw9rcygyFB24eNNFfmeHa
GYhetVq1EJDk1dxSY5vLY3ZFW1eSsoMEEDtz10K5+uBD/AE8drEYufk68+9h
edF7gU7hu3nb5POGe90iyKvbPN1BxrMcCZjLYjOPUEaltNV0eYFYrBnOGP9O
HelApI17AQocjEQp9N5A9P18Fv0fTn7AsxQbAAA=

-->

</rfc>
