<?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.25 (Ruby 3.1.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ma-moq-relay-for-deadline-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.16.0 -->
  <front>
    <title abbrev="MoQ relay for deadline">MoQ relay for support of deadline-aware media transport</title>
    <seriesInfo name="Internet-Draft" value="draft-ma-moq-relay-for-deadline-00"/>
    <author initials="Y." surname="Cui" fullname="Yong Cui">
      <organization>Tsinghua University</organization>
      <address>
        <postal>
          <street>30 Shuangqing Rd</street>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>cuiyong@tsinghua.edu.cn</email>
      </address>
    </author>
    <author initials="C." surname="Ma" fullname="Chuan Ma">
      <organization>Tsinghua University</organization>
      <address>
        <postal>
          <street>30 Shuangqing Rd</street>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>simonkorl0228@gmail.com</email>
      </address>
    </author>
    <author initials="Y." surname="Liao" fullname="Yixin Liao">
      <organization>Tsinghua University</organization>
      <address>
        <postal>
          <street>30 Shuangqing Rd</street>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>lyxceasar@outlook.com</email>
      </address>
    </author>
    <author initials="H." surname="Shi" fullname="Hang Shi">
      <organization>Huawei</organization>
      <address>
        <email>shihang9@huawei.com</email>
      </address>
    </author>
    <date/>
    <area>Applications and Real-Time</area>
    <workgroup>Media Over QUIC</workgroup>
    <keyword>deadline</keyword>
    <keyword>relay</keyword>
    <abstract>
      <t>This draft specifies the behavior of MoQ relays for delivering media before the deadline to decrease end-to-end latency and save transport costs in media transmission. To achieve this, the draft introduces deadline-aware actions prioritizing media streams with earlier deadlines, ensuring timely transmission while minimizing costs.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ma-moq-relay-for-deadline/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/STAR-Tsinghua/draft-moq-for-deadline"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>Media over QUIC (MoQ) is a transport system designed to provide efficient media transport. However, some use cases, such as live streaming, online meetings, and gaming, require the client to receive their media before a specific time, referred to as the 'deadline.' Exceeding the deadline results in dropped data, which can increase latency and negatively affect user experience.</t>
      <t>To address this issue, a deliver-before-deadline transport service can be provided, which is the goal of the Deadline-aware Transport Protocol (DTP) proposed in <xref target="I-D.draft-shi-quic-dtp"/>. DTP leverages stream-level scheduling, active stream canceling, and redundancy coding to prioritize urgent data and prevent outdated data from blocking later data.</t>
      <t>This document proposes the behavior of deadline-aware actions on MoQ relay nodes, extending the basic MoQ relay to provide deliver-before-deadline transmission. The relay design utilizes scheduling, data canceling, and redundancy coding to decrease queuing time, prevent unnecessary re-transmission of overdue data, and ultimately reduce end-to-end latency. By providing better data delivery strategies, MoQ relays with deadline-aware actions can significantly enhance overall user experience in media transport.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</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>
    </section>
    <section anchor="overview-of-deadline-aware-moq-architecture">
      <name>Overview of Deadline-aware MoQ Architecture</name>
      <figure anchor="arch">
        <name>The Architecture of Deadline-aware MoQ</name>
        <artwork><![CDATA[
                      +===========================+
                      :             /=======\     :
                      :    Deadline :Block 1:     :
                      :     -aware  :DDL:xxx:     :
                      :   Canceling \=======/     :
            /-------\ :                 ^         :
            |Block 1| :                 :         :
            |DDL:xxx| :    +---------+  :         :
+---------+ \-------/ :    |Deadline |  :         :
|Publisher|-----------:--->| -aware  |==:         :
+---------+ /-------\ :    |  Relay  |            :
            |Block 2| :    +---------+            :
            |DDL:yyy| :         |  /-----------\  :
            \-------/ :         |  | Block 2   |  :
                      :         |  | DDL:yyy   |  :
                      :         |  |-----------|  :
                      :         |  | Redundancy|  :
                      :         |  | Coding    |  :
                      :         v  \-----------/  :
                      :    +---------+            :
                      :    |Deadline |            :    +----------+
                      :    | -aware  |------------:--->|Subscriber|
                      :    |  Relay  |   /-------\:    +----------+
                      :    +---------+   |Block 2|:
                      :                  |DDL:yyy|:
                      :                  \-------/:
                      +===========================+
                      Deadline-aware MoQ Relay nodes
]]></artwork>
      </figure>
      <t><xref target="arch"/> illustrates the fundamental architecture of Deadline-aware MoQ. This architecture involves the extension of MoQ Publishers and Subscribers, which transport block-like data and add 'Deadline' as a component of Metadata within the header. Relay nodes within this system are equipped with deadline-aware actions, including deadline-aware scheduling, canceling, and redundancy coding. The relay may schedule the data blocks, cancel the overdue ones, and add redundancy code to avoid re-transmission. The relays receive block-like data from the publisher, transfer between relays, make deadline-aware actions, and transmit it to the subscriber.</t>
      <t>The main focus of this draft is the extension of MoQ relays or the 'Deadline-aware MoQ Relay.' The Deadline-aware MoQ Relay <bcp14>SHOULD</bcp14> send data in a block-like style to enable deadline-aware actions. A block is a data unit in the MoQ system, like a video frame. A block can be reliably delivered, partially delivered, or dropped depending on the application logic. A block <bcp14>SHOULD</bcp14> contain a block ID in the block's header.</t>
      <t>Depending on the MoQ implementation, the relay implementation may map the block transmission to different mechanisms of QUIC, such as matching a block to multiple QUIC datagrams or a single QUIC stream. Deadline-aware MoQ Relay <bcp14>SHOULD</bcp14> support various MoQ transport implementations. When the relay receives data without deadline-related information from the endpoint, it <bcp14>MAY</bcp14> convert the data into block type or forward it without utilizing any deadline-aware actions.</t>
      <t>The Deadline-aware MoQ Relay <bcp14>SHOULD</bcp14> support various relay topologies, as discussed in <xref target="I-D.draft-shi-moq-design-space-analysis-of-moq"/>. Each relay topology may require a different MoQ architecture or implementation. Therefore, the deadline-aware actions should act as a plugin that relays can quickly implement regardless of the topology and architecture.</t>
    </section>
    <section anchor="deadline-aware-extension-of-moq">
      <name>Deadline-aware Extension of MoQ</name>
      <section anchor="metadata-for-deadline">
        <name>Metadata for Deadline</name>
        <t>For Deadline-aware MoQ Relay, data block metadata is required to enable deadline-aware actions. Both the endpoint and the relay <bcp14>SHOULD</bcp14> attach the following metadata to each data block when using deadline-aware actions:</t>
        <ul spacing="normal">
          <li>size: the size of the data block in bytes</li>
          <li>priority: the block's relative priority in a single session</li>
          <li>deadline: the expected completion timestamp of the block. The relay can drop overdue data.</li>
        </ul>
        <t>The relay <bcp14>SHOULD</bcp14> maintain track of the metadata of a block until the block misses its deadline.</t>
        <t>Additionally, if the endpoint does not offer metadata in the header of a data block, relays <bcp14>MAY</bcp14> implement other mechanisms to acquire and synchronize deadline-related metadata.</t>
        <t>e.x. The specific methodology for encapsulating metadata needs to wait until the MoQ specification is standardized.</t>
      </section>
      <section anchor="deadline-aware-action">
        <name>Deadline-aware Action</name>
        <section anchor="deadline-aware-scheduling-and-cancelling">
          <name>Deadline-aware Scheduling and Cancelling</name>
          <t>When implementing deadline-aware actions, the Deadline-aware MoQ Relay can utilize the block metadata for scheduling blocks at the block-level. The scheduler <bcp14>SHOULD</bcp14> minimize the total time of queuing and try to meet the deadline requirements of as many high-priority blocks as possible.</t>
          <t>If a block misses its deadline, Deadline-aware MoQ Relay <bcp14>MAY</bcp14> cancel it. In such cases, the endpoints <bcp14>SHOULD</bcp14> be able to accept partially received data and not request for data re-transmission when a block is dropped. Additionally, the relays <bcp14>MAY</bcp14> inform the endpoints and other relays about the cancellation of these blocks.</t>
        </section>
        <section anchor="deadline-aware-redundancy-coding">
          <name>Deadline-aware Redundancy Coding</name>
          <t>To improve reliability and decrease latency, Deadline-aware MoQ Relay <bcp14>MAY</bcp14> introduce redundancy data to blocks close to their deadline or transmitted over a network with a high loss rate. This redundancy can help to prevent the need for re-transmission. If the first relay adds redundancy coding to the data, other relay nodes in the network may benefit from it.</t>
          <t>When redundancy coding is enabled, at least two nodes <bcp14>SHOULD</bcp14> implement a pair of encoder and decoder that comply with the redundancy coding method. The endpoint <bcp14>MAY</bcp14> also implement a redundancy encoder and decoder to utilize the relay's redundancy coding function fully.</t>
          <t>The first node that encodes the data with redundancy coding <bcp14>MUST</bcp14> add redundancy-related information to the metadata of the data block.</t>
        </section>
      </section>
    </section>
    <section anchor="discussions">
      <name>Discussions</name>
      <section anchor="drop-notification">
        <name>Drop Notification</name>
        <t>In situations where a data block is dropped by a relay due to a missed deadline or other reasons, sending an explicit dropping message to other relays and the endpoint can be useful to notify them of the loss of data. The dropping message may include information about the block, such as its ID and metadata.</t>
      </section>
      <section anchor="data-buffer">
        <name>Data Buffer</name>
        <t>Further discussion is required to determine if the relay should implement a buffer for data blocks during forwarding and how such a buffer should be implemented. This buffer may be used for re-transmission purposes and may benefit users with larger delay tolerance, among other potential uses.</t>
      </section>
      <section anchor="clock-synchronization">
        <name>Clock Synchronization</name>
        <t>To enable accurate deadline-aware actions, it is recommended that all endpoints and relays perform clock synchronization.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>Access to the metadata of the Deadline-aware MoQ Relay <bcp14>SHOULD</bcp14> be limited to selected relays. The relay <bcp14>SHOULD NOT</bcp14> access the content of the data block.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="I-D.draft-shi-quic-dtp">
          <front>
            <title>Deadline-aware Transport Protocol</title>
            <author fullname="Yong Cui" initials="Y." surname="Cui">
              <organization>Tsinghua University</organization>
            </author>
            <author fullname="Chuan Ma" initials="C." surname="Ma">
              <organization>Tsinghua University</organization>
            </author>
            <author fullname="Hang Shi" initials="H." surname="Shi">
              <organization>Huawei</organization>
            </author>
            <author fullname="Kai Zheng" initials="K." surname="Zheng">
              <organization>Huawei</organization>
            </author>
            <author fullname="Wei Wang" initials="W." surname="Wang">
              <organization>Huawei</organization>
            </author>
            <date day="26" month="January" year="2023"/>
            <abstract>
              <t>   This document defines Deadline-aware Transport Protocol (DTP) to
   provide block-based deliver-before-deadline transmission.  The
   intention of this memo is to describe a mechanism to fulfill
   unreliable transmission based on QUIC as well as how to enhance
   timeliness of data delivery.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-shi-quic-dtp-07"/>
        </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">
              <organization/>
            </author>
            <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">
              <organization/>
            </author>
            <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.draft-shi-moq-design-space-analysis-of-moq">
          <front>
            <title>Design Space Analysis of MoQ</title>
            <author fullname="Hang Shi" initials="H." surname="Shi">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Yong Cui" initials="Y." surname="Cui">
              <organization>Tsinghua University</organization>
            </author>
            <date day="21" month="October" year="2022"/>
            <abstract>
              <t>   This document investigates potential solution directions within the
   charter scope of MoQ WG.  MoQ aims to provide low-latency, efficient
   media delivery solution for use cases including live streaming,
   gaming and video conferencing.  To achieve low-latency media transfer
   efficiently, the network topology of relay nodes and the computation
   done at the relay nodes should be considered carefully.  This
   document provides the analysis of those factors which can help the
   design of the MoQ protocols.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-shi-moq-design-space-analysis-of-moq-00"/>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>We sincerely thank Wei Cao for his advice and revisions to this draft.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA7Va627byBX+z6eYKj+y24jKZRfortBso9gOYiC3tR0sgqYF
RuRImprkMBxSstZOn6XP0ifrd87M8CJLcVJgBSQWLzPn/p3LKI7jqNZ1pqZi
9Nr8KiqVya1YmErYpixNVQuzEKmSaaYLFcuNrJTIVaqlqCtZWHpjFMn5vFLr
WzuEZaMokbVammo7FbZOoyg1SSFzkEwruajjXMa5+RTzwhgL45beo0eRbea5
tlabot6WWHJ6cvFCiHtCZtaAoi5SVSr8V9SjsRidzp7jD2iPTs8uXoyiosnn
qppGKRiYiuvj2cXJ5ygxhVWFbewUQjQqAuc/RBBMYr9ZWWYa7IKeFbJIxZmS
WXyhc0ixMdXlsjJNSZKyDt6uVSV+fX96NIou1RbP02kkRNxKzhcsV7RWRaPo
6VLXq2aOLc4vZmfxhdXFctXIh14V0ENfA6Mokk29MhAhxlpdgOcPE3HUaFwt
mixzevxgiqW/aarlVIRdxftCg0Wr6y0e2bpSqoawj8Q5HhbLT3hLnKV4lOCN
qXiu9L9wi65NU9Rkr6OVLiRuqFzqbCqSRm9B61ntCUxU2kySIuq4O5qI13LA
3BHRcjf/WOaszk1xaars0ZMnPz1b0s1JYvJooLpXWpqh7vSVLsLtP5bBbHuV
KGll9cw0dWbM5Q57LyfYemjZlyDkbzJvLxu5Ubon80qv8MrPz1b8wG1YmCqH
C6/hb5EuFr2rOI6FnEMUmdRRdLHS1sWgsKVK9EIrK+qVEnO1kmuNMELwtzFt
fVBnpBSS3eHAXOG24mXBa0Vt8D1BRFklEJxxbWL8ERmisEi2HFdWrlWHIVCZ
rS200AcXH/cTcWGETFZa0QqwPHbEmG8NRZu0ScD4DkpBQg7isoIguta/dyyT
KWVuxQahKJSsMq06tML2BA4sYY24z7YDbsRmpTNgoC507vZk1idOt7lO00xF
0T1x6hkjJqLIwYUJcCG+g1a/F9B+D0eF3dpa5WDE6mWhUtJiWZm1TqHExUIn
GiC3C74T8dJsoJhqLKzJlWig8QRqhxS2SVZCWkH28iKDXaBjwTbK4c24xotk
jqV/WKlPjfbmTDKmCDYqlSjN2le6GtpdBtdJWFu0w0JVlWNfOne6H3Q7uS9O
EAJYT8rte0ylbJM5D0grU5ZYD8yWY1I3xEiAILrwHtV3o0It2bdhJblYqKQm
DVRCXZXwUbylYBhynzQFBcvuA7XbBozK4MuxEyXu3LcziarWOlFMf66COdLA
lnbyLY3MKFTo+/HQCy/ard5VpjaJycR3xxfvvqetSmMhJiS+vv7TaXw8cSkA
ER3DBkmc1uXnzxOBt0VGFpZLOLmzY0w3MmGTFfA3Y8ORu7d2Jn4T5R9ASzBH
U6SSlJYYp3zTBQa8plqSpUnj/H6JdE43AFOUOZ0txKIyuZhnJrmkHcgKFT+Y
BCQxSZPTMi/bbSw5EKKIqq5yKEzKMXgFI7d+MpcWDta91AuNLxqxg5CV8ktd
eImm1hlEtwMlsphfo7sW3T41qglIMW711hQFIsYC6bdYHw/wA2ogHEgb5T2c
iMD3NUCa3JjoJftgcyKeb73URHGu6mCAoIMtmZ9KLU0a7AE3A90B5ZNrk0Yo
hGVRgwNVrEgFzKbMst2I2kFpRiFCvCNTkPBt5XSsFgBJviYHUQIlkqAayaJ8
en9+QfUa/RVv3vL3sxNA49nJMX0/fzl79ar9Evk3zl++ff/quPvWrTx6+/r1
yZtjtxh3xeBWNHo9+zBymh69fXdx+vbN7NWI5KgHfktqgXHnJCJ0C2uS70sb
wWeSSs9dtD4/evff/zz+kaL27MXRk8ePf/782V/89PgvP+Jis1KFowas3fpL
uPE2kkA2WdEupNhElrpGITsmoLQrsynESlUEWX/+O2nmH1Px13lSPv7xF3+D
BB7cDDob3GSd3b5za7FT4p5be8i02hzc39H0kN/Zh8F10HvvJnkNldBrrTYU
FzvYSQ48q5D4a+B6UyGt/ps/qH72fR48Pfx5cGDNdHD10L/90T370prAqpg+
J0AUj6d3rxFeLjE9Pn41vbq6unvNUcAi8dHz9nDPmoex+3zckYc+/+z2G6y5
8Xzf7FkzPbTG8+3XPIjD58FwTf/BR//toXvjplXczXDNzbtmnmkL/7+Ju88U
/365aRV38/TpITo7OsDuZwz39K0n2T4dPNknz8E1pIPtdtvX201nAsfCzpod
HYQ1N8LTd5df9p12jaf/LWt6vH09nbM27339miOXIL+Wt3WnGqeeL6/5Kvvs
rBn428H94i/iQ8//etx63zxv5i43VDdf3qPvj62zfhMfQ/lb571bz+2ndd5v
WNM676E1/w/u7kH6s676Czh/PRX3JBKA4AnV0xEVEf2EsD9njD5H0fU1rUMq
1lnWuKLIVaML8mlK9qjY5Z1bUd1ITVr/RV2sTbb223GVGso6kqJFMVcDdd5h
Q8/QNRdcSseZvlRd5Y1GRdwPjNynugAFqclLU3A9DiKqlvw21XRcwSgUDTJV
1aSvwu4x+PeNJQlF7R13V18oCcfUamUNh/LOG/1i+a46uV905/jn1/pRAYnA
CrBhJ74fSmPDjXjQyHBvLtLk2uh0t7jukbRt07qrZm5jiFYZbDV2RkHfSlX1
RqnC7zEG45fqoJqIPU++Fpo7ZdrXtkafuMI3l7DEAlWmdV1iO3XRB7zIS4Cm
idvnQ9GCdvridsvZBZOv5iw1ESw61Z19fdh6m7E2VSHn2SFBJ2LmFrmBBe/U
FCSycz8i6FxsLHhbKagzM9A0Qq1b7ZtoCKdBbRu6FmqnS1nVGiXx4CZNm8Is
gIe85JDG0ZTdnFZkZqmTjoyXOjEI8k5gcXoc+OXr+zaETRQd7+5OEum8zBQj
BRFxMyfnzMMn7Nu5LLuth/Mi6hb1Ar7lpjcJeittc/YEGgV1cxr0f4AZMBE4
xsqcGkNQc1Mj0vyyoskVVCMFjSnDI9f3T+72BT/VX0t0//BHeqFDpKFkMPxv
aF16kvuQsqJFINPUndfQSzU3SX7mCPHbaIOGS4O+akyRguaADARD1x0c4KEJ
om9LRUJiH8iR0pJAzTXurKdie8hjXdx9qzLCbKE05FLK9WWptgjcdlLzt+Gk
hgb2bqIQ21ImIFXIbGu1jc2CHtIE50TCwIO9HSCGWZvsOQjxOMxL1Y5VGOMq
HnaMBzO0nb4e/WSTpXTpskiZNUsOAFkHfKGApFHTZdZzajxcQuUZjcv8TKvl
mvG4xx33/TtaPtkBM7xyr8taNEIOC6LoRe9q10jjXo5A3Pj12ga1pV+BW88N
klzf+Rxkt/7s/UDWNZmI6wOTZWbjRsWeJJGhxz12qKMXjd2TID1pGrUjPn9X
U5cRaMjmldnbBuaYb1GZ4F0/jNtOBwjFAUU5LDx2CO4D3ypGmKg7b5r6dFLC
PFAQFQ6Z4jCk+ZStZV4GNphEP0WTMxDcDqZTPpAG2qJsxshKpwiXYb9WXbgO
8jUFYrWHiwSJAA9dd8N6EJilKU+JCP4BDouhwVKDFYWh2ofyc+cI/dLHEe00
Ow4eTjjTeTa8gbdoMZjqiMQHIZ1JbItkVZmCrHUL1AJlcKwmV05z7egbD1cm
dUFCLq6KRJa2Iev1XalQKmWqG6nrnno4g/q9HGxS1VaDJ0QiuEknHEU7oTLz
hwv3bj86b+s0FsyNEegyihjSW50cduHxvnF2B6HkLn6G2rdwP867YtFXegi0
7l03w/Z69KVh1fqYO15RHn6oWicPJjuHiasrvngUTEcZu8cJbFWSkFGM0yvS
xUovV3EbTIErK0qDUAKSQM+nnf/u8dfxYY1wTnOVrK4n4rRwmd2fxvSd2gYx
UQ0xfrEfJqqse4WQz7Vp1xtQFJBgCGR3FEcPdsfLDE2yq9d8BYXyaBBmLQb6
GOGMvcMkDzA5ZPybck4JmI+GnEM5X3UIYL1d7WSvR3bjBD8l4HMZ+GEFvPE1
Ibypdkmmna/72fcdam9PAfudQgBvb+UkM1b5El13x31cZPsansKcz+goUms6
7ndtkmS/QZ2JlEitpG8L+12JpNFtVrqDCXcIQHqigGdb3WpUTh3OLXRlfT6m
TseKvccNIW+M+/bwjZ4HwsAwFRZzVagFAIZrL03TeQ7621tDCJdBUW0jNjOo
HHxvjN/ae2kHoKgipGa0hVEMAa83Fn/n0oJzztbpzTnZLlGHlS7wW5gnK9JP
OgbEemv30jMDBGKl3N+nQTT9iStGGzi/z2lO8wW3k8S4o2C7HM0i3N6M5/DD
pnRv4evN1s+Lw/TviidXXbpDEooaysBvTN1mAgASnc/Ujf9NyoaKv0Gy60U5
yglWG59zNQ5XHIqlA4cPXiQtA7313Q+cGLUD+ir4Du/ozGWtXPJeQzDwlVRr
Qt/eNVZBzfR6QWJs6aU8SM8hRAeBlEjZA27RIQd28wc10GcHPj7Fh76J4BnN
HfHTy9GkS1LR84bqBpSaTcXcp63Cd2vJVNWqyklDvgZxevR1dN8v57xnh8Ee
YVL3owHfs4QctTIbz2pY53ekY6awqUo9pvhXXBSTLvfChyibyp2wstS9kKez
On/el8lqyb9rcI0HsiuBNgI9p18LOVuWpqYiQPIhn0NuceS66LYW8m540Vbb
SFUNweDh8VHtdAssyOm3WamLMDryGmYX70qlqjj9JEzZDilzmJwrkKTkcAQC
GsEv/bniLEn4XH9/sN3VAELFGeqM2jmAVZmrmx1b/eK4OxfjRG0dTNCIwY/l
9oT26ezN7Ba/w4PylaTa1r3Zta78S5I5amvaZZZcFmYDhF5yMRNdT91v2lT6
dLQAYioad/5GLQaMW/GvVVDdXorflEbZZ9h7eIaZ8g8ZnNbXmhHHqS1MoybR
/wCg04/9DSgAAA==

-->

</rfc>
