<?xml version='1.0' encoding='utf-8'?> 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.17 (Ruby 3.1.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" number="9368" docName="draft-ietf-quic-version-negotiation-14" category="std" consensus="true" submissionType="IETF" obsoletes="" updates="8999" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.15.3 -->
  <front>
    <title abbrev="QUIC Compatible abbrev="QUIC-Compatible VN">Compatible Version Negotiation for QUIC</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-quic-version-negotiation-14"/> name="RFC" value="9368"/>
    <author initials="D." surname="Schinazi" fullname="David Schinazi">
      <organization>Google LLC</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>
          <city>Mountain View</city>
          <region>CA</region>
          <code>94043</code>
          <country>United States of America</country>
        </postal>
        <email>dschinazi.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
      <organization>Mozilla</organization>
      <address>
        <email>ekr@rtfm.com</email>
      </address>
    </author>
    <date year="2022" month="December" day="19"/> year="2023" month="May"/>
    <area>Transport</area>
    <workgroup>QUIC</workgroup>
    <keyword>quic</keyword>
    <keyword>version</keyword>
    <keyword>negotiation</keyword>
    <keyword>compatible</keyword>
    <keyword>incompatible</keyword>
    <keyword>not quite tls</keyword>
    <keyword>tls-ng</keyword>
    <abstract>
      <t>QUIC does not provide a complete version negotiation mechanism but instead only
provides a way for the server to indicate that the version the client chose is
unacceptable. This document describes a version negotiation mechanism that
allows a client and server to select a mutually supported version. Optionally,
if the client's chosen version and the negotiated version share a compatible
first flight format, the negotiation can take place without incurring an extra
round trip. This document updates RFC 8999.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://quicwg.github.io/version-negotiation/draft-ietf-quic-version-negotiation.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-quic-version-negotiation/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        QUIC Working Group mailing list (<eref target="mailto:quic@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/quic/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/quic/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/quicwg/version-negotiation"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>The version-invariant properties of QUIC <xref target="QUIC-INVARIANTS"/> target="RFC8999"/> define a
Version Negotiation packet but do not specify how an endpoint reacts when it
receives one. QUIC version 1 <xref target="QUIC"/> target="RFC9000"/> allows the server to use a
Version Negotiation packet to indicate that the version the client chose is
unacceptable, but it doesn't allow the client to safely make use of that
information to create a new connection with a mutually supported version.
This document updates <xref target="QUIC-INVARIANTS"/> target="RFC8999"/> by defining version
negotiation mechanisms that leverage the Version Negotiation packet.</t>
      <t>With proper safety mechanisms in place, the Version Negotiation packet can be
part of a mechanism to allow two QUIC implementations to negotiate between two
totally disjoint versions of QUIC. This document specifies version negotiation
using Version Negotiation packets, which adds an extra round trip to connection
establishment if needed.</t>
      <t>It is beneficial to avoid additional round trips whenever possible, especially
given that most incremental versions are broadly similar to the previous
version. This specification also defines a simple version negotiation mechanism which leverages similarities between versions and can negotiate between
"compatible" versions without additional round trips.</t>
      <section anchor="conventions">
        <name>Conventions</name>
        <t>The
	        <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 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
      <section anchor="definitions">
        <name>Definitions</name>
        <t>The document uses the following terms:</t>
        <ul spacing="normal">
          <li>In the context of a given QUIC connection, the "first flight" of packets
refers to the set of packets the client creates and sends to initiate the
connection before it has heard back from the server.</li>
          <li>In the context of a given QUIC connection, the "client's chosen version" Chosen Version" is
the QUIC version of the connection's first flight.</li>
          <li>The "original version" "Original Version" is the QUIC version of the very first packet the client
sends to the server. If version negotiation spans multiple connections (see
<xref target="connections"/>), the original version Original Version is equal to the client's chosen version Chosen Version
of the first QUIC connection.</li>
          <li>The "negotiated version" "Negotiated Version" is the QUIC version in use on the connection once the
version negotiation process completes.</li>
          <li>The "Maximum Segment Lifetime" (MSL) represents the time a QUIC packet can
exist in the network. Implementations can make this configurable, and a
<bcp14>RECOMMENDED</bcp14> value is one minute. Note that the term "segment" here originated
in <xref section="3.4.1" sectionFormat="of" target="TCP"/>.</li> target="RFC9293"/>.</li>
        </ul>
      </section>
    </section>
    <section anchor="version-negotiation-mechanism">
      <name>Version Negotiation Mechanism</name>
      <t>This document specifies two means of performing version negotiation: one
"incompatible"
1) "incompatible", which requires a round trip and is applicable to all versions,
and one "compatible" that 2) "compatible", which allows saving the round trip but only applies when the
versions are compatible (see <xref target="compat"/>).</t>
      <t>The client initiates a QUIC connection by choosing an original version Original Version and
sending a first flight of QUIC packets with a long header to the server
<xref target="QUIC-INVARIANTS"/>. target="RFC8999"/>. The client's first flight includes Version Information (see
<xref target="vers-info"/>) target="vers-info"/>), which will be used to optionally enable compatible version
negotiation (see <xref target="compat-vn"/>), target="compat-vn"/>) and to prevent version downgrade attacks (see
<xref target="downgrade"/>).</t>
      <t>Upon receiving this first flight, the server verifies whether it knows how to
parse first flights from the original version. Chosen Version (which is also the Original Version in this case). If it does not, then it starts
incompatible version negotiation, see negotiation (see <xref target="incompat-vn"/>, target="incompat-vn"/>), which causes the client
to initiate a new connection with a different version. For instance, if the
client initiates a
connection with version A and that the server can't parse, the server
starts incompatible version negotiation and negotiation; then, when the client then
initiates a new connection with version B, we say that the first
connection's client chosen version Chosen Version is A, the second connection's
client chosen version Chosen Version is B, and the original version Original Version for the entire
sequence is A.</t>
      <t>If the server can parse the first flight, it can either establish the connection
using the client's chosen version, Chosen Version, or it <bcp14>MAY</bcp14> select any other compatible
version, as described in <xref target="compat-vn"/>.</t>
      <t>Note that it is possible for a server to have the ability to parse the first
flight of a given version without fully supporting it, in the sense that it
implements enough of the version's specification to parse first flight packets
but not enough to fully establish a connection using that version.</t>
      <section anchor="incompat-vn">
        <name>Incompatible Version Negotiation</name>
        <t>The server starts incompatible version negotiation by sending a Version
Negotiation packet. This packet <bcp14>SHALL</bcp14> include each entry from the server's set
of Offered Versions (see <xref target="server-fleet"/>) in a Supported Version field. The
server <bcp14>MAY</bcp14> add reserved versions (as defined in <xref section="6.3" sectionFormat="of" target="QUIC"/>) target="RFC9000"/>) in
Supported Version fields.</t>
        <t>Clients will ignore a Version Negotiation packet if it contains the original
version Original
Version attempted by the client; see client, as required by <xref target="downgrade"/>. The client also ignores a
Version Negotiation packet that contains incorrect connection ID fields; see fields, as required by
<xref section="6" sectionFormat="of" target="QUIC-INVARIANTS"/>.</t> target="RFC8999"/>.</t>
        <t>Upon receiving the Version Negotiation packet, the client <bcp14>SHALL</bcp14> search for a
version it supports in the list provided by the server. If it doesn't find one,
it <bcp14>SHALL</bcp14> abort the connection attempt. Otherwise, it <bcp14>SHALL</bcp14> select a mutually
supported version and send a new first flight with that version - -- this version
is now the negotiated version.</t> Negotiated Version.</t>
        <t>The new first flight will allow the endpoints to establish a connection using
the negotiated version. Negotiated Version. The handshake of the negotiated version Negotiated Version will exchange
version information
Version Information (see <xref target="vers-info"/>) that is required to ensure that version
negotiation was genuine, i.e. i.e., that no attacker injected packets in order to
influence the version negotiation process, see process (see <xref target="downgrade"/>.</t> target="downgrade"/>).</t>
        <t>Only servers can start incompatible version negotiation: clients negotiation. Clients <bcp14>MUST NOT</bcp14> send
Version Negotiation packets and servers <bcp14>MUST</bcp14> ignore all received Version
Negotiation packets.</t>
      </section>
      <section anchor="compat">
        <name>Compatible Versions</name>
        <t>If A and B are two distinct versions of QUIC, A is said to be "compatible" with
B if it is possible to take a first flight of packets from version A and convert
it into a first flight of packets from version B. As an example, if versions A
and B are absolutely equal in their wire image and behavior during the handshake
but differ after the handshake, then A is compatible with B and B is compatible
with A. Note that the conversion of the first flight can be lossy: lossy; some data data,
such as QUIC version 1 0-RTT packets packets, could be ignored during conversion and
retransmitted later.</t>
        <t>Version compatibility is not symmetric: it symmetric. It is possible for version A to be
compatible with version B and for version B not to be compatible with version A. This could
happen
happen, for example example, if version B is a strict superset of version A: A, i.e., if version A
includes the concept of streams and STREAM frames, frames and version B includes the
concept of streams and the hypothetical concept of tubes along with STREAM and
TUBE frames, then A would be compatible with B B, but B would not be compatible
with A.</t>
        <t>Note that version compatibility does not mean that every single possible
instance of a first flight will succeed in conversion to the other version. A
first flight using version A is said to be "compatible" with version B if two
conditions are met: first that (1) version A is compatible with version B, B and
second that
(2) the conversion of this first flight to version B is well-defined. well defined.
For example, if version B is equal to version A in all aspects except it introduced a
new frame in its first flight that version A cannot parse or even ignore, then version B
could still be compatible with A version A, as conversions would succeed for connections
where that frame is not used. In this example, first flights using version B
that carry this new frame would not be compatible with version A.</t>
        <t>When a new version of QUIC is defined, it is assumed to not be compatible with
any other version unless otherwise specified. Similarly, no other version is
compatible with the new version unless otherwise specified. Implementations <bcp14>MUST
NOT</bcp14> assume compatibility between versions unless explicitly specified.</t>
        <t>Note that both endpoints might disagree on whether two versions are compatible
or not. For example, two versions could have been defined concurrently and then
specified as compatible in a third document much later - -- in that scenario scenario, one
endpoint might be aware of the compatibility document document, while the other may not.</t>
      </section>
      <section anchor="compat-vn">
        <name>Compatible Version Negotiation</name>
        <t>When the server can parse the client's first flight using the client's chosen
version, Chosen
Version, it can extract the client's Version Information structure (see
<xref target="vers-info"/>). This contains the list of versions that the client knows its
first flight is compatible with.</t>
        <t>In order to perform compatible version negotiation, the server <bcp14>MUST</bcp14> select one
of these versions that (1) it (1) supports and (2) it knows the client's chosen
version to be Chosen
Version is compatible with. This selected version is now the negotiated
version. Negotiated
Version. After selecting it, the server attempts to convert the client's first
flight into that version, version and replies to the client as if it had received the
converted first flight.</t>
        <t>If those formats are identical, as in cases where the negotiated version Negotiated Version is the
same as the client's chosen version, Chosen Version, then this will be the identity transform. transformation.
If the first flight is correctly formatted, then this conversion process cannot
fail by definition of the first flight being compatible; if the server is unable
to convert the first flight, it <bcp14>MUST</bcp14> abort the handshake.</t>
        <t>If a document specifies that a QUIC version is compatible with another, that
document <bcp14>MUST</bcp14> specify the mechanism by which clients are made aware of the
negotiated version.
Negotiated Version. An example of such a mechanism is to have the client
determine the server's negotiated version Negotiated Version by examining the QUIC long header
Version field. Note that, in this example mechanism, it is possible for the
server to initially send packets with the client's chosen version Chosen Version before
switching to the negotiated version Negotiated Version (this can happen when the client's Version
Information structure spans multiple packets; in that case case, the server might
acknowledge the first packet in the client's chosen version Chosen Version and later switch to
a different negotiated version). Negotiated Version). Mutually compatible versions <bcp14>SHOULD</bcp14> use the
same mechanism.</t>
        <t>Note that, after the first flight is converted to the negotiated version, Negotiated Version, the
handshake completes in the negotiated version. Negotiated Version. If the negotiated version Negotiated Version has
requirements that apply during the handshake, those requirements apply to the
entire handshake, including the converted first flight. In particular, if the
negotiated version
Negotiated Version mandates that endpoints perform validations on handshake Handshake
packets, endpoints <bcp14>MUST</bcp14> also perform such validations on the converted first
flight. For instance, if the negotiated version Negotiated Version requires that the 5-tuple remain stable for the entire handshake (as QUIC version 1 does), then both endpoints need to validate the 5-tuple of all handshake packets, packets received during the handshake, including the converted first flight.</t>
        <t>Note also that the client can disable compatible version negotiation by only
including the Chosen Version in the Available Versions field of the Version
Information; see
Information (see <xref target="vers-info"/>.</t> target="vers-info"/>).</t>
        <t>If the server does not find a compatible version (including the client's chosen
version), Chosen
Version), it will perform incompatible version negotiation instead, see instead (see
<xref target="incompat-vn"/>.</t> target="incompat-vn"/>).</t>
        <t>Note that it is possible to have incompatible version negotiation followed by
compatible version negotiation. For instance, if version A is compatible with version B
and version C is compatible with version D, the following scenario could occur:</t>
        <figure anchor="fig-dual-example">
          <name>Combined Negotiation Example</name>
          <artwork><![CDATA[
Client                                          Server

Chosen = A, Available Versions = (A, B) ------------->
<------------------------ Version Negotiation = (D, C)

Chosen = C, Available Versions = (C, D) ------------->
<------------- Chosen = D, Available Versions = (D, C)
]]></artwork>
        </figure>
        <t>In this example, the client selected C from the server's Version Negotiation
packet, but the server preferred D and then selected it from the client's offer.</t>
      </section>
      <section anchor="connections">
        <name>Connections and Version Negotiation</name>
        <t>QUIC connections are shared state between a client and a server
<xref target="QUIC-INVARIANTS"/>. target="RFC8999"/>. The compatible version negotiation mechanism defined in
this document (see <xref target="compat-vn"/>) is performed as part of a single QUIC
connection; that is, the packets with the client's chosen version Chosen Version are part of
the same connection as the packets with the negotiated version.</t> Negotiated Version.</t>
        <t>In comparison, the incompatible version negotiation mechanism, which leverages
QUIC Version Negotiation packets (see <xref target="incompat-vn"/>) target="incompat-vn"/>), conceptually operates
across two QUIC connections: connections, i.e., the connection attempt prior to receiving the
Version Negotiation packet is distinct from the connection with the incompatible
version that follows.</t>
        <t>Note that this separation across two connections is conceptual: conceptual, i.e., it applies to
normative requirements on QUIC connections, but it does not require implementations
to internally use two distinct connection objects.</t>
      </section>
      <section anchor="client-choice-of-original-version">
        <name>Client Choice of Original Version</name>
        <t>When the client picks its original version, Original Version, it will <bcp14>SHOULD</bcp14> try to avoid incompatible
version negotiation to save a round trip. Therefore, the client <bcp14>SHOULD</bcp14> pick an
original version
Original Version to maximize the combined probability that both:</t>
        <ul spacing="normal">
          <li>The
          <li>the server knows how to parse first flights from the original version.</li>
          <li>The original version Original Version and</li>
          <li>the Original Version is compatible with the client's preferred version.</li>
        </ul>
        <t>Without additional information, this could mean selecting the oldest version
that the client supports, supports while advertising newer compatible versions in the
client's first flight.</t>
      </section>
    </section>
    <section anchor="vers-info">
      <name>Version Information</name>
      <t>During the handshake, endpoints will exchange Version Information, which
consists of a chosen version Chosen Version and a list of available versions. Available Versions. Any version of
QUIC that supports this mechanism <bcp14>MUST</bcp14> provide a mechanism to exchange Version
Information in both directions during the handshake, such that this data is
      authenticated.</t>

      <t>In QUIC version 1, the Version Information is transmitted using a new
"version_information"
version_information transport parameter; see parameter (see <xref section="7.4" sectionFormat="of" target="QUIC"/>. target="RFC9000"/>). The
contents of Version Information are shown below (using the notation from the
"Notational Conventions" section of <xref target="QUIC"/>):</t> target="RFC9000" section="1.3" sectionFormat="of"/>):</t>
      <figure anchor="fig-vi-format">
        <name>Version Information Format</name>
        <artwork><![CDATA[
Version Information {
  Chosen Version (32),
  Available Versions (32) ...,
}
]]></artwork>
      </figure>
      <t>The content of each field is described below:</t>
      <dl>
        <dt>Chosen Version:</dt>
        <dd>
          <t>The version that the sender has chosen to use for this connection. In most
cases, this field will be equal to the value of the Version field in the long
header that carries this data; however however, future versions or extensions can choose
to set different values in the long header Version field.</t>
        </dd>
      </dl>
      <t>The contents of the Available Versions field depends depend on whether it is sent by
the client or by the server.</t>
      <dl spacing="compact">
        <dt>Client-Sent Available Versions:</dt>
        <dd>
          <t>When sent by a client, the Available Versions field lists all the versions
that this first flight is compatible with, ordered by descending preference.
Note that the version in the Chosen Version field <bcp14>MUST</bcp14> be included in this list
to allow the client to communicate the chosen version's Chosen Version's preference. Note that
this preference is only advisory, advisory; servers <bcp14>MAY</bcp14> choose to use their own preference
instead.</t>
        </dd>
        <dt>Server-Sent Available Versions:</dt>
        <dd>
          <t>When sent by a server, the Available Versions field lists all the
Fully-Deployed
Fully Deployed Versions of this server deployment, see deployment (see <xref target="server-fleet"/>. target="server-fleet"/>). The
ordering of the versions in this field does not carry any semantics. Note
that the version in the Chosen Version field is not necessarily included in this
list, because the server operator could be in the process of removing support
for this version. For the same reason, the Available Versions field <bcp14>MAY</bcp14> be empty.</t>
        </dd>
      </dl>
      <t>Clients and servers <bcp14>MAY</bcp14> both include versions following the pattern 0x?a?a?a?a
in their Available Versions list. Those versions are reserved to exercise
version negotiation (see the Versions section of <xref target="QUIC"/>), target="RFC9000" section="15" sectionFormat="of"/>) and will never be
selected when choosing a version to use.</t>
    </section>
    <section anchor="downgrade">
      <name>Version Downgrade Prevention</name>
      <t>A version downgrade is an attack where a malicious entity manages to make the
QUIC endpoints negotiate a QUIC version different from the one they would have
negotiated in the absence of the attack. The mechanism described in this
document is designed to prevent downgrade attacks.</t>
      <t>Clients <bcp14>MUST</bcp14> ignore any received Version Negotiation packets that contain the
original version.
Original Version. A client that makes a connection attempt based on information
received from a Version Negotiation packet <bcp14>MUST</bcp14> ignore any Version Negotiation
packets it receives in response to that connection attempt.</t>
      <t>Both endpoints <bcp14>MUST</bcp14> parse their peer's Version Information during the handshake.
If that leads to a parsing failure (for example, if it is too short or if
its length is not divisible by four), then the endpoint <bcp14>MUST</bcp14> close the
connection; if the connection was using QUIC version 1, that connection closure
<bcp14>MUST</bcp14> use a transport error of type TRANSPORT_PARAMETER_ERROR. If an endpoint
receives a Chosen Version equal to zero, or any Available Version equal to zero,
it <bcp14>MUST</bcp14> treat it as a parsing failure. If a server receives a Version
Information where the Chosen Version is not included in Available Versions, it
<bcp14>MUST</bcp14> treat it as a parsing failure.</t>
      <t>Every QUIC version that supports version negotiation <bcp14>MUST</bcp14> define a method for
      closing the connection with a version negotiation error.

      For QUIC version 1,
version negotiation errors are signaled using a transport error of type
VERSION_NEGOTIATION_ERROR; see
VERSION_NEGOTIATION_ERROR (see <xref target="iana-error"/>.</t> target="iana-error"/>).</t>
      <t>When a server receives a client's first flight, the server will first establish
which QUIC version is in use for this connection in order to properly parse the
first flight. For example, the server determines This may involve examining data that QUIC version 1 is in use
by observing that not part of the Version field handshake transcript, such as parts of the first Long Header packet it receives
is set to 0x00000001. header. When the server then processes the client's Version
Information, the server <bcp14>MUST</bcp14> validate that the client's Chosen Version matches
the version in use for the connection. If the two differ, the server <bcp14>MUST</bcp14> close
the connection with a version negotiation error. For example, error.</t>

<t>In the specific case of QUIC version 1, the server determines that version 1 is in use by observing that the Version field of the first Long Header packet it receives is set to 0x00000001. Subsequently, if a the server
receives the client's Version Information over QUIC version 1 (as indicated by
the Version field of the Long Header packets that carried the transport
parameters) and the client's Chosen Version is not set to 0x00000001, the server
will
<bcp14>MUST</bcp14> close the connection with a version negotiation error.</t>
<t>Servers <bcp14>MAY</bcp14> complete the handshake even if the Version Information is missing.  Clients <bcp14>MUST NOT</bcp14> complete the handshake if they are reacting to a Version Negotiation packet and the Version Information is missing, but <bcp14>MAY</bcp14> do so otherwise.</t>
      <t>If a client receives a Version Information where the server's Chosen Version was
not sent by the client as part of its Available Versions, the client <bcp14>MUST</bcp14> close
the connection with a version negotiation error.</t>
      <t>If the Version Information was missing, the endpoints <bcp14>MAY</bcp14> complete the
handshake. However, if error. If a client has reacted to a Version Negotiation packet and the server's Version Information was missing, the client <bcp14>MUST</bcp14> close the connection with a version negotiation error.</t>
      <t>If the client received and acted on a Version Negotiation packet, the client
<bcp14>MUST</bcp14> validate the server's Available Versions field. The Available Versions
field is validated by confirming that the client would have attempted the same
version with knowledge of the versions the server supports. That is, the client
would have selected the same version if it received a Version Negotiation packet
that listed the versions in the server's Available Versions field, plus the
negotiated version.
Negotiated Version. If the client would have selected a different version, the
client <bcp14>MUST</bcp14> close the connection with a version negotiation error. In
particular, if the client reacted to a Version Negotiation packet and the
server's Available Versions field is empty, the client <bcp14>MUST</bcp14> close the connection
with a version negotiation error. These connection closures prevent an attacker
from being able to use forged Version Negotiation packets to force a version
downgrade.</t>
      <t>As an example, let's assume a client supports hypothetical QUIC versions 10, 12,
and 14 with a preference for higher versions. The client initiates a connection
attempt with version 12. Let's explore two independent example scenarios:</t>
      <ul spacing="normal">
        <li>In the first scenario, the server supports versions 10, 13, and 14 14, but only 13
and 14 are Fully-Deployed Fully Deployed (see <xref target="server-fleet"/>). The server sends a Version
Negotiation packet with versions 10, 13, and 14. This triggers an incompatible
version negotiation negotiation, and the client initiates a new connection with version 14.
Then
Then, the server's Available Versions field contains 13 and 14. In that
scenario, the client would have also picked 14 if it had received a Version
Negotiation packet with versions 13 and 14, therefore 14; therefore, the handshake succeeds
using negotiated version Negotiated Version 14.</li>
        <li>In the second scenario, the server supports versions 10, 13, and 14 14, and they
are all Fully-Deployed. Fully Deployed. However, the attacker forges a Version Negotiation
packet with versions 10 and 13. This triggers an incompatible version
negotiation
negotiation, and the client initiates a new connection with version 10. Then Then,
the server's Available Versions field contains 10, 13 13, and 14. In that
scenario, the client would have picked 14 instead of 10 if it had received a
Version Negotiation packet with versions 10, 13 13, and 14, therefore 14; therefore, the client
aborts the handshake with a version negotiation error.</li>
      </ul>
      <t>This validation of Available Versions is not sufficient to prevent downgrade.
Downgrade prevention also depends on the client ignoring Version Negotiation
packets that contain the original version; see Original Version (see <xref target="incompat-vn"/>.</t> target="incompat-vn"/>).</t>
      <t>After the process of version negotiation described in this document completes, the version
in use for the connection is the version that the server sent in the Chosen
Version field of its Version Information. That remains true even if other
versions were used in the Version field of long headers at any point in the
lifetime of the connection. In particular, since during compatible version
negotiation the client is can be made aware of the negotiated version Negotiated Version by the QUIC long
header version during compatible  version negotiation (see <xref target="compat-vn"/>), clients <bcp14>MUST</bcp14> validate that the server's
Chosen Version is equal to the negotiated version; Negotiated Version; if they do not match, the
client <bcp14>MUST</bcp14> close the connection with a version negotiation error. This prevents
an attacker's ability to influence version negotiation by forging the Version long header Version
field.</t>
    </section>
    <section anchor="server-fleet">
      <name>Server Deployments of QUIC</name>
      <t>While this document mainly discusses a single QUIC server, it is common for
deployments of QUIC servers to include a fleet of multiple server instances. We
therefore
Therefore, we define the following terms:</t>
      <dl spacing="compact">
        <dt>Acceptable Versions:</dt>
        <dd>
          <t>This is the set of versions supported by a given server instance. More
specifically, these are the versions that a given server instance will use if a
client sends a first flight using them.</t>
        </dd>
        <dt>Offered Versions:</dt>
        <dd>
          <t>This is the set of versions that a given server instance will send in a
Version Negotiation packet if it receives a first flight from an unknown
version. This set will most often be equal to the Acceptable Versions set,
except during short transitions while versions are added or removed (see below).</t>
        </dd>
        <dt>Fully-Deployed
        <dt>Fully Deployed Versions:</dt>
        <dd>
          <t>This is the set of QUIC versions that is supported and negotiated by every
single QUIC server instance in this deployment. If a deployment only contains a
single server instance, then this set is equal to the Offered Versions set,
except during short transitions while versions are added or removed (see below).</t>
        </dd>
      </dl>
      <t>If a deployment contains multiple server instances, software updates may not
happen at exactly the same time on all server instances. Because of this, a
client might receive a Version Negotiation packet from a server instance that
has already been updated updated, and the client's resulting connection attempt might
reach a different server instance which hasn't been updated yet.</t>
      <t>However, even when there is only a single server instance, it is still possible
to receive a stale Version Negotiation packet if the server performs its
software update while the Version Negotiation packet is in flight.</t>
      <t>This could cause the version downgrade prevention mechanism described in
<xref target="downgrade"/> to falsely detect a downgrade attack. To avoid that, server
operators <bcp14>SHOULD</bcp14> perform a three-step process when they wish to add or remove
support for a version:</t> version, as described below.</t>
      <t>When adding support for a new version:</t>
      <ul spacing="normal">
        <li>The first step is to progressively add support for the new version to all
server instances. This step updates the Acceptable Versions but not the
Offered Versions nor the Fully-Deployed Fully Deployed Versions. Once all server instances
have been updated, operators wait for at least one MSL to allow any in-flight
Version Negotiation packets to arrive.</li>
        <li>Then, the second step is to progressively add the new version to Offered
Versions on all server instances. Once complete, operators wait for at least
another MSL.</li>
        <li>Finally, the third step is to progressively add the new version to
Fully-Deployed
Fully Deployed Versions on all server instances.</li>
      </ul>
      <t>When removing support for a version:</t>
      <ul spacing="normal">
        <li>The first step is to progressively remove the version from Fully-Deployed Fully Deployed
Versions on all server instances. Once it has been removed on all server
instances, operators wait for at least one MSL to allow any in-flight Version
Negotiation packets to arrive.</li>
        <li>Then, the second step is to progressively remove the version from Offered
Versions on all server instances. Once complete, operators wait for at least
another MSL.</li>
        <li>Finally, the third step is to progressively remove support for the version
from all server instances. That step updates the Acceptable Versions.</li>
      </ul>
      <t>Note that, during the update window, connections are vulnerable to
      downgrade attacks for partially-deployed versions. Acceptable Versions that are not Fully
      Deployed.  This is because a client cannot distinguish such a
      downgrade attack from legitimate exchanges with both updated and
      non-updated server instances.</t>
    </section>
    <section anchor="application-layer-protocol-considerations">
      <name>Application Layer
      <name>Application-Layer Protocol Considerations</name>
      <t>When a client creates a QUIC connection, its goal is to use an application layer application-layer
protocol. Therefore, when considering which versions are compatible, clients
will only consider versions that support one of the intended application layer application-layer
protocols. If the client's first flight advertises multiple Application Layer Application-Layer
Protocol Negotiation (ALPN) <xref target="ALPN"/> target="RFC7301"/> tokens and multiple compatible
versions, it is possible for some application layer application-layer protocols to not be able to
run over some of the offered compatible versions. It is the server's
responsibility to only select an ALPN token that can run over the compatible
QUIC version that it selects.</t>
      <t>A given ALPN token <bcp14>MUST NOT</bcp14> be used with a new QUIC version that is different from the
version for which the ALPN token was originally defined, unless all the
following requirements are met:</t>
      <ul spacing="normal">
        <li>The new QUIC version supports the transport features required by the
application protocol.</li>
        <li>The new QUIC version supports ALPN.</li>
        <li>The version of QUIC for which the ALPN token was originally defined is
compatible with the new QUIC version.</li>
      </ul>
      <t>When incompatible version negotiation is in use, the second connection which that is
      created in response to the received version negotiation Version
      Negotiation packet <bcp14>MUST</bcp14> restart its
application layer application-layer protocol
      negotiation process without taking into account the
original version.</t> Original Version.</t>
    </section>
    <section anchor="considerations-for-future-versions">
      <name>Considerations for Future Versions</name>
      <t>In order to facilitate the deployment of future versions of QUIC, designers of
future versions <bcp14>SHOULD</bcp14> attempt to design their new version such that commonly
deployed versions are compatible with it.</t>
      <t>QUIC version 1 defines multiple features which are not documented in the QUIC
invariants. Since, at the time of writing, QUIC version 1 is widely deployed,
this section discusses considerations for future versions to help with
compatibility with QUIC version 1.</t>
      <section anchor="interaction-with-retry">
        <name>Interaction with Retry</name>
        <t>QUIC version 1 features Retry packets, which the server can send to validate the
client's IP address before parsing the client's first flight. A server that
sends a Retry packet can do so before parsing the client's first flight. A Therefore, a
server that sends a Retry packet therefore might not have processed the client's
Version Information before doing so.</t>
        <t>If a future document wishes to define compatibility between two versions that
support retry, Retry, that document <bcp14>MUST</bcp14> specify how version negotiation (both
compatible and incompatible) interacts with retry Retry during a handshake that
requires both. For example, that could be accomplished by having the server
first send a Retry packet in the original version Original Version, thereby validating the
client's IP address before attempting compatible version negotiation. If both
versions support authenticating Retry packets, the compatibility definition
needs to define how to authenticate the Retry in the negotiated version Negotiated Version
handshake even though the Retry itself was sent using the client's chosen
version.</t> Chosen
Version.</t>
      </section>
      <section anchor="interaction-with-tls-resumption">
        <name>Interaction with TLS resumption</name> Resumption</name>
        <t>QUIC version 1 uses TLS 1.3, which supports session resumption by sending
session tickets in one connection that can be used in a later connection; see connection (see
<xref section="2.2" sectionFormat="of" target="TLS"/>. target="RFC8446"/>). New versions that also use TLS 1.3 <bcp14>SHOULD</bcp14>
mandate that their session tickets are tightly scoped to one version of QUIC; QUIC,
i.e., require that clients not use them across multiple version and that servers
validate this client requirement. This helps mitigate cross-protocol attacks.</t>
      </section>
      <section anchor="interaction-with-0-rtt">
        <name>Interaction with 0-RTT</name>
        <t>QUIC version 1 allows sending data from the client to the server during the
handshake,
handshake by using 0-RTT packets. If a future document wishes to define
compatibility between two versions that support 0-RTT, that document <bcp14>MUST</bcp14>
address the scenario where there are 0-RTT packets in the client's first flight.
For example, this could be accomplished by defining which transformations are
applied to 0-RTT packets. That document could specify that compatible version
negotiation causes 0-RTT data to be rejected by the server.</t>
      </section>
    </section>
    <section anchor="special-handling-for-quic-version-1">
      <name>Special Handling for QUIC Version 1</name>

      <t>Because QUIC version 1 was the only QUIC version that was published
      on the IETF Standards Track version of QUIC
published before this document, it is handled
      specially as follows: if a client is starting a QUIC version 1
      connection in response to a received Version Negotiation packet, packet and
      the version_information transport parameter is missing from the
      server's transport parameters, then the client <bcp14>SHALL</bcp14> proceed as if
      the server's transport parameters contained a version_information
      transport parameter with a Chosen Version set to 0x00000001 and an
      Available Version list containing exactly one version set to
      0x00000001.  This allows version negotiation to work with servers
      that only support QUIC version 1.  Note that implementations which that
      wish to use version negotiation to negotiate versions other than QUIC
      version 1 will need to <bcp14>MUST</bcp14> implement the version negotiation mechanism
      defined in this document.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The security of this version negotiation mechanism relies on the authenticity of
the Version Information exchanged during the handshake. In QUIC version 1,
transport parameters are authenticated authenticated, ensuring the security of this mechanism.
Negotiation between compatible versions will have the security of the weakest
common version.</t>
      <t>The requirement that versions not be assumed compatible mitigates the
possibility of cross-protocol attacks, but more analysis is still needed here.
That analysis is out of scope for this document.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="quic-transport-parameter">
        <name>QUIC Transport Parameter</name>
        <t>IANA has registered the following value in the "QUIC Transport Parameters"
registry maintained at &lt;<eref target="https://www.iana.org/assignments/quic"/>&gt;.</t> <eref brackets="angle" target="https://www.iana.org/assignments/quic"/>.</t>
        <dl spacing="compact">
          <dt>Value:</dt>
          <dd>
            <t>0x11</t>
          </dd>
          <dd>0x11</dd>
          <dt>Parameter Name:</dt>
          <dd>
            <t>version_information</t>
          </dd>
          <dd>version_information</dd>
          <dt>Status:</dt>
          <dd>
            <t>permanent</t>
          </dd>
          <dd>permanent</dd>
          <dt>Specification:</dt>
          <dd>
            <t>This document</t>
          </dd>
          <dd>RFC 9368</dd>
        </dl>
      </section>
      <section anchor="iana-error">
        <name>QUIC Transport Error Code</name>
        <t>IANA has registered the following value in the "QUIC Transport Error Codes"
	registry maintained at &lt;<eref target="https://www.iana.org/assignments/quic"/>&gt;.</t> <eref brackets="angle" target="https://www.iana.org/assignments/quic"/>.</t>
        <dl spacing="compact">
          <dt>Value:</dt>
          <dd>
            <t>0x11</t>
          </dd>
          <dd>0x11</dd>
          <dt>Code:</dt>
          <dd>
            <t>VERSION_NEGOTIATION_ERROR</t>
          </dd>
          <dd>VERSION_NEGOTIATION_ERROR</dd>
          <dt>Description:</dt>
          <dd>
            <t>Error
          <dd>Error negotiating version</t>
          </dd> version</dd>
          <dt>Status:</dt>
          <dd>
            <t>permanent</t>
          </dd>
          <dd>permanent</dd>
          <dt>Specification:</dt>
          <dd>
            <t>This document</t>
          </dd>
          <dd>RFC 9368</dd>
        </dl>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="RFC8999" to="QUIC-INVARIANTS"/>
    <displayreference target="RFC9000" to ="QUIC"/>
    <displayreference target="RFC7301" to="ALPN"/>
    <displayreference target="RFC8446" to="TLS"/>
    <displayreference target="RFC9293" to="TCP"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="QUIC-INVARIANTS">
          <front>
            <title>Version-Independent Properties of QUIC</title>
            <author fullname="M. Thomson" initials="M." surname="Thomson">
              <organization/>
            </author>
            <date month="May" year="2021"/>
            <abstract>
              <t>This document defines the properties of the QUIC transport protocol that are common to all versions of the protocol.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8999"/>
          <seriesInfo name="DOI" value="10.17487/RFC8999"/>
        </reference>
        <reference anchor="QUIC">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar">
              <organization/>
            </author>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson">
              <organization/>
            </author>
            <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">
              <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>
        <reference anchor="ALPN">
          <front>
            <title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title>
            <author fullname="S. Friedl" initials="S." surname="Friedl">
              <organization/>
            </author>
            <author fullname="A. Popov" initials="A." surname="Popov">
              <organization/>
            </author>
            <author fullname="A. Langley" initials="A." surname="Langley">
              <organization/>
            </author>
            <author fullname="E. Stephan" initials="E." surname="Stephan">
              <organization/>
            </author>
            <date month="July" year="2014"/>
            <abstract>
              <t>This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7301"/>
          <seriesInfo name="DOI" value="10.17487/RFC7301"/>
        </reference>
        <reference anchor="TLS">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla">
              <organization/>
            </author>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8999.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7301.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="TCP">
          <front>
            <title>Transmission Control Protocol (TCP)</title>
            <author fullname="W. Eddy" initials="W." role="editor" surname="Eddy">
              <organization/>
            </author>
            <date month="August" year="2022"/>
            <abstract>
              <t>This document specifies the Transmission Control Protocol (TCP).  TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet.  Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion.  This document collects and brings those changes together with the protocol specification from RFC 793.  This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793.  It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements.  It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state.  The TCP header control bits from RFC 793 have also been updated based on RFC 3168.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="7"/>
          <seriesInfo name="RFC" value="9293"/>
          <seriesInfo name="DOI" value="10.17487/RFC9293"/>
        </reference>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9293.xml"/>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>The authors would like to thank Nick Banks, Mike Bishop, Martin Duke, Ryan
Hamilton, Roberto Peon, Anthony Rossi, and Martin Thomson <contact fullname="Nick Banks"/>, <contact fullname="Mike Bishop"/>, <contact fullname="Martin Duke"/>, <contact fullname="Ryan
Hamilton"/>, <contact fullname="Roberto Peon"/>, <contact fullname="Anthony Rossi"/>, and <contact fullname="Martin Thomson"/> for their input and
contributions.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA809a28byZHf+1dM5A+xDyRtrX1JVpvNhbLsrABb9knaXQRB
sBhymlTH5AwzPZTMNZzfcr/lftnVq18zTUreJMBtEFicRz+qqutdNePxWHWm
W+mT4mWz3pSdma108YNurWnq4kIvm87ARfh70bTFf39//lKVs1mrb0/oR/LS
haqaeV2uYayqLRfd2OhuMf771szHtzzguA4Djo9fKBjlubLb2dpYvN3tNvDu
+avr12pedvBouzspbFepstXlSXHdlrXdNG2n7pY8vaq365luT1QFj5+oeVNb
XdutPSm6dqvVdoPX4dfvvv76a3Wr6y08VBTLttluToojHOEIfvO0Rz827QdT
L4s/4W28vi7NCq7jBv6IW5k07RKvl+38Bq7fdN3Gnjx9io/hJXOrJ+6xp3jh
6axt7qx+igM8xReXprvZzmTIu+XTDFTwsRUuuotm4Mcn/PrENLkXnz4A5JOb
br06Uh/07q5pKwTFuMBn6Q95nv6O3qHfc49l+mnq3oW66XCgThfdytIV+Hdc
L1W57W6almaC/xfwJmDjbFJcAbjq8mdDF5lkzspbU6U3AJAnxZ+aZgnU9ebN
S7pmu1ZrAM7xb549K6brzQ0ARZdwsXhfth/uyh09NTcdkM7bZlt3pamLH4y+
o+utXsKegNan/FhTwcxfv3j24rn8hheQ6L6vYTOwmg5RUTQLmEm3Zl7SU5oJ
o7KyVsL6H5d4dQKASTf7alJcajtv2lUZbfYVDJZeh72WtfmZYI4r/9msVsl0
+kP7x7ZbrGkKpcbjcVHOABrlvFOKzmLVwFoRFZu2AVjqoiTErTTgRbAbY7ZY
6/kNzGnXxWzb4Wo7XVZFU692SkawMASAlM4+gLmwuoWBiq6BpyuDZxQulx3d
czPg3/OV0XVXzG8aqwtj1bYu53O96UogmElxfWMsLHa+XeNDMMu8NTOa6/Aq
cSpVrlZwqHBrPEdZV9GyrF7pOVws1ttuC4/uCrvdIMsAZMrgk+LdBgfGuyNl
FtGCf215ybVfCI6O992CwjCFvQGuJCCWo7Awre2KxcosbzqE2brsRsnr+N68
BBiVH3SxWZVzXdwB/TYE/vm2bZH/wH39EfCqgA/h9K3Z9GEmjK24fP2SeNtE
CGJtqgrWoR4V50DHTbWd0xFW1wE/Y1Pflq0payKTjW47wxROJPTp06/w3/H5
xQ/Ty/PpxfXVtzAHTvH5M2BqYWrYssqJh005/6A7oqSqISq0Gz03i11x09zR
nupq0xiYFnj5vLPF3Q3A2XSq1XMNrBPWUANt0CociI/denARXz979gwWIfhP
qXFr71nWP0WxI9mVtvWvO15A/A6SXbnQQGtrRCuupVkwsZqaqYBmaYo5bL1D
mqn1HdBNXWvCD9HAYZpVefx/+tTDFgBotmNEISk5np49T5YhsdLwVLnUtKX9
IAQS+xGXyURDO+528WDAZomiR/cMRAdgptWmbDsEVBmf8MaB965hUjDIv3DP
NITFJ/xZhFG6Ow1UBE+rrukIdpWxfyMyk7172u6fISZPJP4M11Fbi/Dbvws7
AgI2c0BbVVl/ZItwZAnfHsUKBDqQkrE3NDdwnVrrSlcA1XP4aWErNSBtbsoV
AeG2AVkIQxvmVNG4fHAQZ8WmAa2J6FPTZnD/aglnqWbMrhtLfKVlAK4CSJBz
gXJSVkhsZo36C06LiNuAbmearVWeXRLYBFpzhkG5so2wA2TFlrB0mHsrBpej
NuvmNcR/HCbDCmG7SCgDZKujwHCPwvOOjeZhhvzx0SNQVmsADhES80TQhApU
hWxx9Pb7q+ujEf9bXLyjvy9fAeFcvjrDv6++m7554/9Q8sTVd+++f3MW/gpv
vnz39u2rizN+Ga4WySV19Hb6Z7iD2zx69/76/N3F9M0RnqEuIVJEFCBmBjyp
7nQLyEGuUFrlpGaF75y+fP+//3P8ArklMMqvjo+RW/OP3x3/9gX8QJrh2VC8
y09A906Vm40G7BtE6gpAvjFAKUDdJWAIOHdd3OhWA/z+4y8Imb+eFL+fzTfH
L/4gF3DDyUUHs+QiwWx4ZfAyAzFzKTONh2ZyvQfpdL3TPye/Hdyji0wnZ8Q/
IzoJjNdqlj2LBvkU8ghAy9qeAIBA5rJYAEMGuAHzNj6OxMoCN2AWeRSrC0f4
uLAWhXrqAijbnUmru+h2Iq9IoljRgurKsqQzfGTgQVXEgmamQR4BLXXFDeAX
9Oa2KmYwarFom3UkUye/ZDt7dKgjFKcFPZII92bhhpdh4M0YIrQGBP5R05ql
qQP/whH3jgc/dzKOk/0eXLAMD6Ros8X5Isu77AbsTZDKq84gewsrtcVjqxG0
nz5FFz9/fsKQ6K8Xl6v/vmXWfkDbhAFlE7z+HpgDQIbaaB4kcKhJG6l7kIYr
c0cduY2DjJ9ra731YMPUb8uPZr1dF1d6SQfijQE9wKyBFT9+e/XmCRAu8CjY
k5Ap3gKyoVUF8Q/T6o+GhJOoxyDB2w+AiJ60RwlAShVxRdjAwiy3LetkSPJo
IEWnvbgtV1tU31CXBGW43nagUl40sdKHx7U4srz8I+JuDmEAT4VWG6D1SgD1
fPJicoxY+a/rl+9JC/3q6+efP5M8yWoHb728U/vUDdRt1rpkzQR0KVQRI2Ut
xsQJbkQdxfb2kegdLVCUaUn8RkoHAgVmBaa+AlmNXhlWqbygHCkWAnheozEJ
PKJaWzDEka8BsKKRUQUm2UFja9HfkYYSrSIMSmeETghegcMxYV4qnMsxKevI
I2ZTOzwZjRVraHCeYAsKDzLdT5iGN2QcrxTVetXAo8DvKt2mh19lVOhJcR0f
0mR8QMVqi4axQ/55pOITV/j0CZc5RtUfNi3YugNrHqU4HMcKF9B4ExTsIsJT
BLic1p4Ac3xbE7Mh67QhlU0HjRdo7q5etiU6ALoO4GDdwvwNxsb3G3iYzS9G
uEk3O4qtLPg/ky/gHS63KEQ+1EgvaN91DerzVifv2yBW+igknms677KgqdAc
LEBPbkEExiSfOxmjggHiniOQOJ18Xno5LYw/lor7zK/KLEDoRoCcFK+blvwi
ZY12DfsKVIaA+4O5BU+9A0GgyLtLHWg5DuxecyYmASeaMLcDRzanAAaYsNwF
psdYSURtbPDWsaSaOrTD45V62DunI7/iwWF1viNUvFsN5/bvW43iB6dC82cR
wwcZPhNSWLYjRsOmozZEft6g6sk2sdwOiNlR0RD1gjro/UX1rmho2CFeSBVO
1O3kGMIWgoAxZMs5u4y2XkZuipvyljdWzszKgPmMhzfdrQp8zGlbDpDOxFls
Ix8B7tUgcGoBY239WpQ3nkH/qJvt8iZSkiyjNLXr/HoSnufUUhQB6NiRseBh
XkpARXISHCLKcKBYvT6Pz3ZOiH56FB9rFhv7D1BWhQEREiSEzKEyXg22bkU1
YaNEWHyhS2AlGv3BffUY4aY7BcB8RyyjcjNYx6f5ufFipTWKPjKviivv1nGb
Boa6qkjcKNkfEiXYsAUqUXChChbuYyJDNLmrVEf5zeS5E3s8ldozEapxL+lM
WBZIZlk35MM84K0xxKfRCChNbZMj7jkXiBm93uB8s1108r4RHh2JnVi0sheB
12Dvcd8hEfk1IPLbFs9tRG3nZ7JJmlVF4HHASWV8Rvwd8lqNYnbMdGI1Bnn4
kHtQoARj6Ft3Jleo6YpD3UMoMj1M8C0Cdkk5GynjZilnMFZffxeAT4p3yLTu
jNXEHt26ej5wNfAnentRREly3EmYxMcWwzl4SpyAMSiy7/b4xUXLy4wKBBd8
p84bTLbYIQai9kxDhASqdmVv0EAQxpbx09PE+iOq5csgbE1PbSt6apuo16Rf
YUix1QlIEt3sDk7mUtdbOJqAhgmYHPRo3Yj+hcpS/TfYFAzn9FKDai1ro+gl
XrFMjL3SGYNslDlQSr1DrZzpiS0m4pH3ssgToWZbOD8OUcSBY2ijYIu85TgI
gFj8+NUBbhv8cH32b4Hni6FAKgErTqfs/wJ7qYIzBBsaenVH8Ci6J0tTiaMs
sWuQltWpMLFYNKMRgHQzNB/cXonnp4rcHP2HbYeHE0i3eejLp5NiKj7iEiUy
aZJ+I1MVtlrObLMCoxWFKjkMmIWYFjaCfps1+unx8ZkGXcIA56m2rWNe/jCQ
oGZttigXnW7T26JrE9wiEqFjfypwT24pujXtW9IMjdj3kkCD3fxgeVmLUfxm
rYuq7EpgRug1t/1Iz7Px5fW1h9+82a4qcnsSgVVun9GcaAS2usOcgLXp8Gxh
3BxdV46C3Q5Y1zIcG7W79RreMvOTnLYW8E3EpPrw8SglOOEbpzQqk17/6amo
F7QbdYOuVtaHhRAiOmCYlxjeNnOSIXCd3X5+TSfx81PlTVFBBoar8HmMkJdr
PqxX15evpm+BHMu1tqykRxNGA6g9AxDl7DaoHHegJa7iibotRW3Jtqb9ymyI
mevvT1/5aYXe7hxSh1SHFHsqDyA8k4cc/cWa9m0Wxz4Cjv4VflCTQxAlCczm
cK2cUcd69lBQAZHONStaEcmJ54AtBS+Ipmncl9XeQEj3cKcYHwuKZKHdxc5n
4glrzHbgGZKdZ8+vH2wkThIcbP+R7Rn8uMaEHu/0ajUWpXOiXgfKHQ1I1zs4
py6WUKJtgabHRyIYZpoUlMYQhiINAQkEnzddfyXpVoGZUGIDGSe4DDSMmDcI
eZ0q5hkgJ9jVMjiMyHQCAKxQm8M0HsvImavuyDNIy5BVMmWhB2fCvnHctQNH
6vdIaeBUsf5atu2OXwt730PyPTcCBl9xk6ytRSjkGKk3DEbC00prt2tWXvJD
q2DxutG29Qp9vo3TKL3HErZ7xbG61W6EWk36nrEDLtmJAviQofsuX1QrMLom
e+gd8EGcUIbWH9HhaTrUhPzYMb+YweSR0rkmIgOtoly2mjzkzq2F2sYej6YC
EgFwslvIYz55gWmQ7PwZrtMZbMg1ty06l9CDyny1Vn6pTJoeiGQtAqG0VfAf
r1FskoSjBCzelZ3rumxNQ25in2DBmwOkl3e4AR9oSTmljHt3Y1Y6Ymvrckeb
3Kep9Qz12Ez/UTzCeWdO3p+611sT3C/O7/ORcp3SZ3NeWBBf23mHGnvGH+sl
cmTPkoHWRCpZ4Jds77GfE3hUyumH/Bf9WUGxd879jG83dWVGMCOtWiw4RCoj
z+re4h4fP0lMTSSpx189CU7ZAxDNKysuzk9TR+ZT1tgLyQFT0i/5LeeLirYj
hqqVbAjUnjPEoLxznSRs4PyssbSaIw5J9AyPDKv1N2UVjA9RZXAiZOppPJF8
jZjgw8TC5xus8ppUG3L0ocAvLbu5W73PpuRgm7LIwcsssMMOOj4VxvogAD7O
s6ILEBVYXM/EuUKHNEbOjtVOlt0hnw+jRjLdx+1IWqpFaVYhHajbp6jPNGvW
jhy+EUe3w6FBLosxCtVD4sA9S8QbHBbe4mDQl9lgGAWeemHLoV5T1sSdRvS8
8uPwaZE8M5wySmncuWCAWLmkS1FQJOKKKudZmHpLjbRhsleikY1NfLkSYag0
RhYxPy7xE2aIB1aGw3OGlo/ZRhEqb8CIe9BLsZFPEHHr86sa5ayZLvgVfQCE
fMfo+UkiZAcoWJIGlIUHMeF16c5hZmuPmSKBW4ux44KEA46t8hy7F3KXNX7j
BR6ezZg2SdQpeAp41EpXyzhu4ByY9cHdIYNhscobRIdMHAsa7hJkyFuXqTfk
7LaQjJUtr5SZhMdTrJSMIut8eOgdD9sLbWICKrjAfLQ+hNWHtH2+1092U1ol
Xq+1xO/xaG42mFSX8TKMhJcm7/DjvGTFEZ/4DbY4vcTP82lUrjE50My3oHP6
sFtmyWsYmQJibOl57c7J3dtyZSrRK2mHzkHic/jCO8y70CPt3qaD3xsis2zl
lp0LFuYA7SP3Xs34z3G3RXJvMdUb1ELKOu0FziJf5+Oh9wQN3yciFVJVV2Gi
IRl2vBOdzIjmLwilMLaHzB5UqZ5IJWImsPWVJuQCqGDng9v9YA1lnadzvuSD
6pihEPX0FsstEtchsUkn2jL8xcUhIj1wEHj0ngNywZe5FT/ugSSvXT0hTkyi
3hHSvcEqSb0fSeQiiWkfii86MXTvBJytRtEHdfjRDBkfdDickvfyZe7WGWuC
IVPOWytsJTVzMIlOlPrHP/4hYaniwf9dcfKGEhr5FqPWGcr4tngMN06fFOP4
vz+o34/3/Je1cmAU2MvLJ9F0L/dNBzfO7pmu8KOc7RuFp0PAfDopHi3MclyB
vBk7qU8FW98egXE2I+syXuwrfuboM5kiqZMiOp1ez3+ZCW5mgKBcGAw9ddG5
2VCmInpoz7xdGwY3XRjdn5cGRWvIyPU5dfj6PiMzJNlJrUucjIfqHFVjoPcn
zgtPikRcIP5Axs/hQxQ0wBCGVWm6biZLhw4sMwK280PeuzglqZAt7OcbOers
N324moZQkLEpZkZ6RxwztPnxsiG8c/GstsY6A/VeJhPpor1cb0bZocDS40w2
zxPna2ZVC8sOUNiDttcCAwwlAhEpnDhh1QuUAplisAT4ZRLvPRRyRrS6oFOg
4V7KTR8uwcQmvyFxPptw8I6NbICsJPqEzcQkzRqgbJ4iFS7tDtTTmgXbbU/3
agaJuTZUrpBsk8f7RRWcHQWaKCekkeIax9zixNEZxjF9HI9PF/Azw670dy75
x0nh4BOSk7gxmI+G7t5+olCQm5hx4Ysg7k2VovKbW53kQdJ5bslu6QXuSTXH
RQBPUINcJRhrjQmu5mftfGbMYcGynvmkHedPPHFZscIL43S4TB7NoXQ4N1Iu
dTjnXfVMIPDfMNSPw1qIKNw9cm4DlMEUJwneG1rbqtI2BLr7ap1zOY3Ec1hW
qBgacuPV+i5JoQo2EStvKusDTJNpY7vw06Ogsil1ljVCggafBPpz4wlfojJh
oG3LXDhjD5beJVh68ey2gu6BXeSCZ97G3ljnjSMAB3FBpkWoyUzKnfrrTexi
I8p8ZVrHGPKWGJkqgb9gnBX98lh9y86tjkuN6p7dkNZqJVPbIg6tspuWwg/q
SF7/KSKqI34at4+UD6IH2InTu10mzm8nL0KiEmc9UXFBzajILYNFO5ahzDSm
jjwO/mJgaKLcyqlSRxdyCQg+KvU5wlxG5/1i4Q/CRRTPLNmpom98PH7+1ZMR
XM6oa3irmEwmI/U50dhuzZiHdOpabqrX9NeR5LgJNHCdlHzGho2J0w8JDCde
E5UxT9QJsY9E/LCWVqMvGqs9hM6lWpKNSxYzrr4ADW+sGVPkARU+wWtwrsuk
jIGz7VO7y61ZUp+aeqlc2rWLgbHbT8j0G+SXVM222JIHyLMMirEAOCSwAnyK
csLJC4mR8ShdF9dh4zldqnfqSEuAbN3C9xqUld5QsUgUHGL7C8sb0JKKuCIs
Nk3scpl24yu8PZwDMfYj68o0mNdVR4cXtSLGhTZ7F/BtVTj790QoRhyd4EQ0
JCtJkmQ5gklIE5WmeXhJVOescl4VcTgqUqOMgsr7KXG5KlR1BoCRK3m93tau
Jlf3GLGXbbSm4ANljTvc4moPjKpVt6CstrtRyFCa/lloxlF9R7k0yE7CAEqs
b0AZW5VfgDKe6UtQpl5jyuz4TG9WzS5OHHXxeOePoAfWRBC5lFJmn4RLRF+a
12s9/IWSnQLIIWiM/Vq9LlEyWAat+iJ0Sygc+Ia2FmwEgH4f8wp3Deqnplz8
2GJkPZ6i7S7Hh6dy0QvYC6i0DSnpIlKVZ1fekfnatSRAM6fVpbdT9uIByQFZ
GNgDuwmwaQuaPszxLadkzIkLu/TYJNEN30Mx7BKDPZSjIkCyrDrUoYtnH/+r
5P8pn76VWRQCCLHYxME9lHc+9ZfUA93Ojc1rvmQ0RbzXZgUdx9CIgXPZ8AyD
AmKgk38+1NrEijCgLdXMznxZyXsuOGEVLSQjKjXN1KAYSn3jTEiJqoEOVGK4
vtnaQsJgQI1UFUwa+Af2nJOuEvS7UArcixcFSRAUbI7D7CS/Ar1ksQNZKK6c
WS1JQPST1si+gNjYj1L/ibS9uc+S2SxrndThDOpvorzrJGsSzmE/azJrHcfp
zwSZYTnNNJSKYOU3gLBXl+Is4VmJJUhNkgGr/CoIgAfzwfsb2O8rQjOv8N0d
DDq+QUGsmRu7LfUzmpU6TTM1WHl2WQRwlDY68VHF2lROOZawKjU6KLn0s6Tx
8EmMkFKiwKKX2sSCvmsa1D5bku9modBsXel6ibyAWWBlQOiQcJ1heHbbPvGh
2ZDjzHuYrxqJCMW+HtOvgqVsYtZyh7p6CjMcEVavaHhqgRFp4WAUwqKRsncb
XVxfTi+u3r+7vP7p/fRy+vbV9avLn15dXr67pIhQ1J0jtOMo+7zf634/67ah
IhrE/4Cz9Z5TLi6MSYXkwS7tEAO8DCciojXkzKIQmu+HCBgpsSwaMl70M6gH
rEipV7eYOphgIbXzckyZRnadUjB576ah5DKF2IrCKb3is9xQhEKWdD1SyIoD
ely8oXBAy1Vkt+2hC/XDq8ur83cXP128+tO76/Mp1sMzXTjbzQBfHtM7FIqQ
LLQhnrKWfZIKQhKI7/p8f2kK0Y/+S91yxkaJ8+alFQkoH549pNGpXp5WFOxx
sXphrb1gml+BwsDUDF/ylUxDUydJqXiDxsd3bHw4R2Jggor0O1J+n318xv8d
T4p+3hQxENGGdC+7JHMehvlDUaiv7OXb9E4MjDC/0Vb1NL8AfZ0aiLxX9g6i
0B3OTWxO/SIijxmw99Z7GsuBIeH+Da6hh8rHlNLDjX8qZ7Nl8TfEnJO7ZLJy
JrQ/Rso7OeyTXrHmEMgu87yP+Rh4io6HlxFfBDzJrhEFYMg8izzz9OGe3nJB
ACleL5s5kdUWhS9QFuaYa/T0P0EPPjyb3UKJCZwWWdsoEbRi8rmeZ12cHjEp
vmNHg5CXrBE9I9SQilW4g6oPZlQ/eE0DGOTRup+TBxikiK3YRUkrRsXpgUVr
qs8ZIgLYZzKxKjy8q7wZ6MYjdwL1Z+BeBn2vcVDDo2JBZ755GBBIQipP36iN
WI0TwbjCKFgmW41m85aOtxU9m1tErLk6CEe2jtFgk4F6fu37ITkqNqstJw0e
yMoZAssvP1OePopc6vfS2SHee16rYb5NoLoHHw5az72goGIBtMEfdk7U/eu/
pgTZoWJsvUXmDVBgtGTicM6ja5Ah4m55nxnW4FNzHVajvKkHp7VX4wUs6Ncu
Ez/wG687JkU1sdSyxfGzUXH8FXfqOH7hEBi5vFA034CKE7LwbVJYm29NoJwJ
mNQWHH81Kd7QUjGHvpF6O5CZ5P3E0VzWgUvfSJodsdrjbo1yZ7S3sefskICN
+ZYix9h9Uy6i+trzkeVrqidx6I3b+gRzociRaLzv/mIk/bkDw3qJTp+y7nc5
zRFgr03DAzs04HQw4HWq9h06Mj5d/fi5X+85WyPY0yiBfobjUlabARgQhDNZ
018GOLcGmo+jrKnN7YpqsO/TViKDgzQ4BEKgI6lU+mWEJGjYUW9erkZNSSgS
/sHRgzEHPPQ2z9hgsD10w9M+v4dkPI8o/iUk84zovZZOWl9CMgSrX0A2EcW4
1rAL3H2OfmC4A7Ihd/D20JBv1EVp5LZHVw/QGwknIWuTevcOYeRU8u0Cmy5K
QGLgv5uo4PPcBJ+ndD/00aEYnegY29M5Uu1z5w2i/t747iUCTn26cOQrzwFj
0EfQ5waPYv1F7TX1XDuxxO/RJfy2S0MEadK6sxAyqrKobJzraqlRt5TzLbgE
KTSUukNThVomyVSDOaJgH5wgbuTCPjfxlK6kP9mw3dwgzxgYFchWX2h8sB1T
jHI7LCvYk/aPd3yyv4uLuvvZDk9Jif7QrHdsQA0tziRSO1yO8zzuXLde8gT8
y1TKawnS4ZGxKlK/UCUKzW9C54PcWORSbZe95hwqDvC6wK56JCmhxZkPnEVd
jR8lugO6sbjoLT4iSI7cP3a+Jb9LkqDnQ33GRVXXDdVyqyozoQsd0RY5aFQW
NDk+4ssbXIGNZNuCEvcjmcrCD8WLSGrWoN3k1LcnTgKUBHjjbKW0rC20AaHg
JXcX6q1hUrylYg/XFgibZONg6F1ukwYVvnYnOw67+5C5oLXtSMqpafkSQCyO
6DfUuW9P96+Bil2wovJgtt8iCVb0VshREaxjReO07rfG1ZK3Rv12G+DR9SBV
IoMtfG+kpDhauA4HG8jLJBXgnGTlt0vqTYW+7ablKKnTjykxBLu67Qkw7wFk
anlI5mlEKSilI+6BtUvoFVfDoxHA7qWPPxni3g8XWO/3OkrpxusNFde5WU7K
TMA6aL/074Hpp5MiFyzu78lvZ+8BByED9EGCwrXwlnpb1x2iJHuLqv28x4Ll
FxfVD1nGqYTYJYFgFE4b1wELUR+23iXu18ckaYroIitXLTDcHRc189Krod8T
TG7cOffp6AceuVSrpcSm2JsxOLQUEoBJsSFSMt+OupB7TZ6UBldg1kaJIMU+
YpL0HeoQ4FtB+KRgTe03yj2lzoFRRGqQJHZzbXAPtVFl9aHxyIfkEyFDu5Ai
JE442VjllNF8oDpt9kieC9Basa8Mxj6oO1Q/Sg3czOXccnGaOKZdvoYvbHNl
LVii3mo9Bttg4xVSh48dsERLPeKwm5k/WK4VlbTGk52duMBSVUVJH/JM1EjA
J9yK1wEn5mpMmH4J1GcBi5QKVCWDsAoU+hFwQhJ1A+6fJuboOLA7oPvYt+uG
11Eb3QEnqmXePex4UrxDYs8daRgtNBAQ2h8VAQ13pRHYUEzbUqF48fbqTWif
j2qwqcdMVgdtMw6Ity1+vEag6wNKbJEfAnIGsAKIMKndz7oIBM40ObhF8g9x
gwLYKK30tam9dlJws4QvXCsMujcba8+ShVD7+UkDcn4QmfKRSI448eF0UQ+H
pLT1Jrpxcix5g7obe1H0yynqoLfol1PUPnj8vyQpWWyfzQSnD4vU7CLJAH4I
k0mrhaP0FidiTA1sfDSohrrdrmrdOve25/TK9QPG1ZLpi9sdV478Y2cya4ou
f8/7r6W1ANeGLLfI46VAvi9PGAArvQSta42LdanuUntEKXXC3sjVXTf12In6
zMEDE2/Kba2J2N6UO3jgfdt0zbyhfG9rKt1KRYtLVOi3yR+2rkcvxbLBEgnr
vyRTuwbaNNMKZ8IvItFMSWkJp8/J1IgbVl4S1TJ4Erw5z8FepwLTyz0d3JEV
nkNxKWCFTo1a6v612V4kqd9sxdVq6EhFHcBUeZjGZ/vx9M37iyf4UQn8Azuh
//b5s2NSLT5oKd6LOuX3K3Zstj8BNYUbbKfw24n6Fwktq3YrgX56V0DTiPDN
VJ4ARLpg8oi3RBLRTHBENNxDUZoBF7hH3pnLAQCO6mZmZ4jf4TA/yLjySiTb
qdim0ZC+36JrCC7+FJRO9yQ2+lApgo+JjVhHGBwD0c6fuNqFxlDSKMmlIQeH
Qlq/Lw3HnAQbLCmqcYnSIYoFnC+KuPm+mezuQiYb4dcfovvHxy35x9xdZ7B+
4e75CxT7ulTF8zsBf3/JtssRSkRb7COj5WFzLOI91TABUgf/eW6GON+y1dLT
E51pe89L9hsOrmt0V9LHDblv5Zw+dEcIypSiqUc9dkrwfs31GU40pZ2OFmAd
w1lymQWxob8YVna41p2SPNviJdV/SqwNZz6iHKPHcQLTJqpcKH9iv9xqpwYy
rf91AiIBgzZXv5WCfNbIczNP2/LBp1Zz6qc4DoN3mgp5/efVLLZNI7PTfXlC
3NB3+M0jTBMZpp3dAcyJbHnxIyWeDyap4JqcD9HTBx/2BtCrDXd7S3t/0dbT
yX1n7k5jky3v5L3UXbsbgMhDhG73v4gV2cfUjVbXg/4ToRDw/D0q56hWuY/T
uDzMvWIMk519plzZKedUjBfD3ScakBJfMqyKhi2ywwbnLDtXkBA4WCbpeqlH
JFteJguqGjIgGpe+JQgMjdlAt+KEePED5zvhJe3nGB6iO2Bz1J1kDec7JmGp
ao71PEbdLG4UQZ8ViVjiE64X5u/4IZ3QXE5BLaOIHa3IdzzBcQdpmXRspRQE
ORNcx62TCLkJ3yIRE0ZsKu5dneBmTzCNcQZjuaCg1H4fIEHhOfk4UNotA1BH
wOo72Yuo9hLH6Z2UWIeQhny+SRd1bIkRLxXFcTUnDcBj7m32E7UG0vxNOG7b
H97sQE1ZkMykeN69vfj2cYnrN1fk+1vTV00G7II+xoHPHE+eOybh5bzV9Onf
6P2od79ydzsT2mbXSSzK62ezECospaNTnGifNoX/avIVsuJfwaroA5cvXvwG
a6ouglBxoQWM9aJRIOsXsaSk9ZAPxZm26K+V4iXIJVC1nIMlyl9+qQfqzDcK
m4aPfHk+b0kif9JzlOIjrluAF01uoNI1eZXAk4qYrbEhlctremLhoYTAvEVY
Jj5Mo4+9OhGqV7JYp47NA2S7jwhJXSGVIvd6gKRf4InMWhWVNM92Qo9JY2gJ
JNzHK9UDeaU/rTRJjlcqxxpowa6BjU+ibTksljav7nccS4vde9zP+3sz3M9/
x1MEq2sVWHpLn7VBpqweoK6TvUhzXN8qj3WlQyFu+YgOj0po5L6RrZZW9v2C
V4zB8mcoi+8AjysqpnC1C04QHivlAhY9wrmTBiVkiuE3wPHry3DI8OuM1y06
FHrHRm22Mwcrl0ASBXSdxYk0haUQ/hOZmMUsrTlO4lxgys5HNZtlWG95aQ1C
rMmXD2l9Hz6QI0P+lHwbdlg8T3kFnFCshh16Mi9YHyzrfaeCVBPuPSOt1A4O
48JYlBZ2cLEhCd5ZsL00hEHGO6cuZ6pyuFBYZkb4uyBYzC4zpRPExYTl5IgY
Hscvy/H6fFQeqZ8tfjn+PWU4qjbuf3/Wfc6LYxtbm7cOk6/UOo6j2NkIw/bb
MLjqTD7HfsrEExp/nDbXiSglfpcSMQfeCgyw7x27ZpOVb7rK49xGwkytpvYz
kvvidREeYG9avPP5VfnavGLYkUJlaZJitHE3C/4oR9ANe3uJ+i3GZ9EJglyL
EsKB7+qZjgjmosaSSiRRSvwICtH1TdKGp4jb11rvvZJ+3NG8TuhyUji7xVha
wYx5QczdfNZceVmudpZ9tBzP5O8Jy9daiffHz6AHAHuZohoS6qpSajmfXkwH
lAKCnxB07bHy3mEF7BZ8gysolpgc34r5E5xL8kFGJpqjfSPZI8UjtDtKw3Hs
pyt+/5e/Pr7puo09efr07u5uguVok6ZdPgWImmVNTqunAPz5kz/ghx9wNkx0
ePbxGASNH7+4gH/xeoadKQVipttSfsRGw8UaRYG6ir+L5XMnHMD2ZQRkwPWK
6u1eNpXGz1qFarp/Gnph4H8T+HBo/LW3RlCpMwo5bxyMeEmef0QfIP+XAhl7
6OFXaykk4Fu/sgPz06MyvfIZhqm36xmC99sjioK7divIUCg0RLrRynxwlcn1
h+ICW0Sdwl9w6t7inVNg+c0GfpCCUJxtUUm93JW1+q5cm1WHsYTLBqaBId5r
/DWtYfh6B1cB2Cz/5eXrm2ZtG/9pPIOBjs2WC4xQBrYGDjrHf/4P4oi3BKCF
AAA=

-->
</rfc>