MIME-Version: 1.0
References: <20200417101932.GA2035@wakko.flat11.house>
In-Reply-To: <20200417101932.GA2035@wakko.flat11.house>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 20 Apr 2020 19:36:55 -0400
Message-ID: <CAHbrMsDa-gZfqWVbb1LZNRJTHmgE5FPo2k2KKUJfQ3vLn7GETw@mail.gmail.com>
To: Alessandro Ghedini <alessandro@ghedini.me>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
 micalg=sha-256; boundary="00000000000097a9b005a3c1606b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xLsyi0tKQ8OiZ0y2qzmkTB4G6qI>
Subject: Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-httpssvc-02
Precedence: list

--00000000000097a9b005a3c1606b
Content-Type: multipart/alternative; boundary="0000000000008ca73805a3c1602f"

--0000000000008ca73805a3c1602f
Content-Type: text/plain; charset="UTF-8"

On Fri, Apr 17, 2020 at 6:20 AM Alessandro Ghedini <alessandro@ghedini.me>
wrote:

> Hello,
>
> First off, I have started implementing support for SVCB and HTTPSSVC as
> part of
> the dnspython library [0] and I'd be interested in doing some interop
> testing
> with other people's implementations.
>
> I also have a few comments/questions about the draft, apologies if they
> have
> already been discussed in the past (haven't been following the draft from
> the
> start).
>
> 1. For interop testing purposes it would be very helpful if the draft
> listed
> commonly agreed upon code-points for the new RR types. Ideally in the form
> of an
> official early assignment from IANA, but if that's not possible picking a
> couple
> of codepoints at random from the "private use" range would also be
> helpful. In
> my implementation I'm currently using "65481" for SVCB and "65482" for
> HTTPSSVC.
>
> 2. The structure of the draft is a bit odd, as it lists a bunch of examples
> before introducing any of the records. This was a bit confusing to me, so
> I'd
> suggest moving sections 1.5 and 1.6 _before_ the examples (that is,
> immediately
> after the introduction). It might also be a good idea to just move the
> examples
> to an Appendix instead.
>

Noted as https://github.com/MikeBishop/dns-alt-svc/issues/135

3. Would it make sense to move the ESNI/ECHO config paramenter to the
> ESNI/ECHO
> draft instead? This way the DNS draft wouldn't need to depend on the ESNI
> draft
> (so e.g. if ESNI ends up taking longer, this draft could be published
> without
> having to wait for it).
>

That's an interesting question.  My main concern with separating it is that
ECHO is the only reason we need to disable fallback, and the need to
support clients that can't use fallback is a major factor in the design.


> 4. What is the point of differentiating between AliasForm and ServiceForm?
> Like,
> couldn't the draft just say that the SvcFieldValue is an optional field
> and be
> done with that? It seems like not having to explicitly differentiate the
> two
> cases would simplify the draft a bit without sacrificing much, though I
> might
> be missing something.
>

It's true that there is no great distinction to an authoritative server.
However, the resolution procedure is quite different.  If there is an
AliasForm, the resolver should follow only one RR (ignoring all the
others), and should re-query SVCB.  Otherwise, it should follow all the
RRs, but only querying A and AAAA.

(To an authoritative, the only distinction I can think of is that "." is
not allowed for AliasForm, because it represents a reference cycle.)


> 5. Section 2.1.1 says
>
>    The presentation format for SvcFieldValue is a whitespace-separated
>    list of elements representing a key-value pair, with an absent value
>    or "=" indicating an empty value.
>
> It took me longer than I'd like to admit to understand the "with an absent
> value
> or "=" indicating an empty value" part. I'd suggest rewording that
> paragraph to
> something like:
>
>    The presentation format for SvcFieldValue is a whitespace-separated
> list of
>    key=value pairs (e.g. "key123=value1 keys456=value2"). When the value,
> or
>    both the value and the "=" are omitted, the value should be interpreted
> as
>    being empty.
>
> Or something better :)
>

Noted as https://github.com/MikeBishop/dns-alt-svc/issues/136


> 6. In Section 2.2 it says (in reference to param field values):
>
>    o  an octet string of the length defined by the previous field.
>
> It might be good to say here that the format of this octet string is
> defined
> according to the corresponding SvcParamKey, and then reference section 6
> for
> ths currently defined keys. The same applies for section 2.1.1 for the
> presentation format.
>
> 7. Section 4.3 says:
>
>    All DNS servers SHOULD treat the SvcParam portion of the SVCB RR...
>
> Should it be SvcFieldValue instead of SvcParam? "SvcParam" is not mentioned
> anywhere else.
>

You're right.  https://github.com/MikeBishop/dns-alt-svc/pull/137

8. Maybe I'm missing something, but the following sentence in Section 6.4
> seems
> wrong:
>
>    When SvcDomainName is ".", server operators SHOULD NOT include these
> hints,
>    because they are unlikely to convey any performance benefit.
>
> My understanding is that ipv4hint and ipv6hint are the way to solve the
> ESNI
> multi-CDN problem


Not exactly.  Hints are not required for that.  Instead, the requirement is
that each RR contains a matched SvcFieldValue and SvcDomainName, from the
same CDN.  The A/AAAA lookup for the SvcDomainName then provides the IPs.

The purpose of IP hints is to reduce resolution latency in that scenario,
only in the case where the recursive resolver is not SVCB-aware, by
avoiding the need to wait for the A/AAAA lookup.

, so let's say I have "www.example.net" that CNAMEs to both
> "cname.cdn-a.example" and "cname.cdn-b.example". A client queries both A
> and
> HTTPSVC concurrently for "www.example.net", and receives two answers (the
> answer
> to the A query points to CDN A, while the answer to HTTPSSVC points to CDN
> B):
>
>     www.xample.net      3600 IN CNAME cname.cdn-a.example
>     cname.cdn-a.example 3600 IN A 192.0.2.1
>
> and
>
>     www.xample.net      3600 IN CNAME cname.cdn-b.example
>     cname.cdn-b.example 3600 IN HTTPSSVC 1 . alpn=h3 esniconfig="..."
>
>
(You have two distinct CNAMEs for "www.xample.net" listed there.
Technically this is not allowed by the CNAME specification.  However, we
can ignore that issue.)


> My understanding is that in this case the client could end up connecting to
> 192.0.2.1 (CDN A) with CDN B's ESNI config (or e.g. with the wrong ALPN).


No, this is not possible.  When using B's ESNI config, the only allowed IP
addresses are those for cname.cdn-b.example.

In this case (as with any case where SvcDomainName=".", IP hints would not
provide a performance advantage, because HTTPSSVC is always queried in
parallel with A/AAAA, so the record for cname.cdn-b.example will come back
along with the corresponding IPs anyway.

...

> 9. Speaking of multi-CDN, AFAICT the problem is mentioned only once in the
> whole
> draft and only in relation to ESNI. However this is not ESNI-specific and
> also
> affects e.g. HTTP/3 as per the example above. So I think it would be
> useful to
> go into a little more detail on this.
>

OK, please suggest text.


> 10. Section B.2: s/pther/other/
>

Will fix.


>
> Cheers
>
> [0] https://github.com/rthalley/dnspython/pull/452
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

--0000000000008ca73805a3c1602f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 17, 2020 at 6:20 AM Aless=
andro Ghedini &lt;<a href=3D"mailto:alessandro@ghedini.me">alessandro@ghedi=
ni.me</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex">Hello,<br>
<br>
First off, I have started implementing support for SVCB and HTTPSSVC as par=
t of<br>
the dnspython library [0] and I&#39;d be interested in doing some interop t=
esting<br>
with other people&#39;s implementations.<br>
<br>
I also have a few comments/questions about the draft, apologies if they hav=
e<br>
already been discussed in the past (haven&#39;t been following the draft fr=
om the<br>
start).<br>
<br>
1. For interop testing purposes it would be very helpful if the draft liste=
d<br>
commonly agreed upon code-points for the new RR types. Ideally in the form =
of an<br>
official early assignment from IANA, but if that&#39;s not possible picking=
 a couple<br>
of codepoints at random from the &quot;private use&quot; range would also b=
e helpful. In<br>
my implementation I&#39;m currently using &quot;65481&quot; for SVCB and &q=
uot;65482&quot; for HTTPSSVC.<br>
<br>
2. The structure of the draft is a bit odd, as it lists a bunch of examples=
<br>
before introducing any of the records. This was a bit confusing to me, so I=
&#39;d<br>
suggest moving sections 1.5 and 1.6 _before_ the examples (that is, immedia=
tely<br>
after the introduction). It might also be a good idea to just move the exam=
ples<br>
to an Appendix instead.<br></blockquote><div><br></div><div>Noted as=C2=A0<=
a href=3D"https://github.com/MikeBishop/dns-alt-svc/issues/135">https://git=
hub.com/MikeBishop/dns-alt-svc/issues/135</a>=C2=A0</div><div><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex">
3. Would it make sense to move the ESNI/ECHO config paramenter to the ESNI/=
ECHO<br>
draft instead? This way the DNS draft wouldn&#39;t need to depend on the ES=
NI draft<br>
(so e.g. if ESNI ends up taking longer, this draft could be published witho=
ut<br>
having to wait for it).<br></blockquote><div><br></div><div>That&#39;s an i=
nteresting question.=C2=A0 My main concern with separating it is that ECHO =
is the only reason we need to disable fallback, and the need to support cli=
ents that can&#39;t use fallback is a major factor in the design.</div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
4. What is the point of differentiating between AliasForm and ServiceForm? =
Like,<br>
couldn&#39;t the draft just say that the SvcFieldValue is an optional field=
 and be<br>
done with that? It seems like not having to explicitly differentiate the tw=
o<br>
cases would simplify the draft a bit without sacrificing much, though I mig=
ht<br>
be missing something.<br></blockquote><div><br></div><div>It&#39;s true tha=
t there is no great distinction to an authoritative server.=C2=A0 However, =
the resolution procedure is quite different.=C2=A0 If there is an AliasForm=
, the resolver should follow only one RR (ignoring all the others), and sho=
uld re-query SVCB.=C2=A0 Otherwise, it should follow all the RRs, but only =
querying A and AAAA.</div><div><br></div><div>(To an authoritative, the onl=
y distinction I can think of is that &quot;.&quot; is not allowed for Alias=
Form, because it represents a reference cycle.)</div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">
5. Section 2.1.1 says<br>
<br>
=C2=A0 =C2=A0The presentation format for SvcFieldValue is a whitespace-sepa=
rated<br>
=C2=A0 =C2=A0list of elements representing a key-value pair, with an absent=
 value<br>
=C2=A0 =C2=A0or &quot;=3D&quot; indicating an empty value.<br>
<br>
It took me longer than I&#39;d like to admit to understand the &quot;with a=
n absent value<br>
or &quot;=3D&quot; indicating an empty value&quot; part. I&#39;d suggest re=
wording that paragraph to<br>
something like:<br>
<br>
=C2=A0 =C2=A0The presentation format for SvcFieldValue is a whitespace-sepa=
rated list of<br>
=C2=A0 =C2=A0key=3Dvalue pairs (e.g. &quot;key123=3Dvalue1 keys456=3Dvalue2=
&quot;). When the value, or<br>
=C2=A0 =C2=A0both the value and the &quot;=3D&quot; are omitted, the value =
should be interpreted as<br>
=C2=A0 =C2=A0being empty.<br>
<br>
Or something better :)<br></blockquote><div><br></div><div>Noted as=C2=A0<a=
 href=3D"https://github.com/MikeBishop/dns-alt-svc/issues/136">https://gith=
ub.com/MikeBishop/dns-alt-svc/issues/136</a></div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">
6. In Section 2.2 it says (in reference to param field values):<br>
<br>
=C2=A0 =C2=A0o=C2=A0 an octet string of the length defined by the previous =
field.<br>
<br>
It might be good to say here that the format of this octet string is define=
d<br>
according to the corresponding SvcParamKey, and then reference section 6 fo=
r<br>
ths currently defined keys. The same applies for section 2.1.1 for the<br>
presentation format.<br>
<br>
7. Section 4.3 says:<br>
<br>
=C2=A0 =C2=A0All DNS servers SHOULD treat the SvcParam portion of the SVCB =
RR...<br>
<br>
Should it be SvcFieldValue instead of SvcParam? &quot;SvcParam&quot; is not=
 mentioned<br>
anywhere else.<br></blockquote><div><br></div><div>You&#39;re right.=C2=A0=
=C2=A0<a href=3D"https://github.com/MikeBishop/dns-alt-svc/pull/137">https:=
//github.com/MikeBishop/dns-alt-svc/pull/137</a>=C2=A0</div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
8. Maybe I&#39;m missing something, but the following sentence in Section 6=
.4 seems<br>
wrong:<br>
<br>
=C2=A0 =C2=A0When SvcDomainName is &quot;.&quot;, server operators SHOULD N=
OT include these hints,<br>
=C2=A0 =C2=A0because they are unlikely to convey any performance benefit.<b=
r>
<br>
My understanding is that ipv4hint and ipv6hint are the way to solve the ESN=
I<br>
multi-CDN problem</blockquote><div><br></div><div>Not exactly.=C2=A0 Hints =
are not required for that.=C2=A0 Instead, the requirement is that each RR c=
ontains a matched SvcFieldValue and SvcDomainName, from the same CDN.=C2=A0=
 The A/AAAA lookup for the SvcDomainName then provides the IPs.</div><div><=
br></div><div>The purpose of IP hints is to reduce resolution latency in th=
at scenario, only in the case where the recursive resolver is not SVCB-awar=
e, by avoiding the need to wait for the A/AAAA lookup.</div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">, so let&#39;s say I have=
 &quot;<a href=3D"http://www.example.net" rel=3D"noreferrer" target=3D"_bla=
nk">www.example.net</a>&quot; that CNAMEs to both<br>
&quot;cname.cdn-a.example&quot; and &quot;cname.cdn-b.example&quot;. A clie=
nt queries both A and<br>
HTTPSVC concurrently for &quot;<a href=3D"http://www.example.net" rel=3D"no=
referrer" target=3D"_blank">www.example.net</a>&quot;, and receives two ans=
wers (the answer<br>
to the A query points to CDN A, while the answer to HTTPSSVC points to CDN =
B):<br>
<br>
=C2=A0 =C2=A0 <a href=3D"http://www.xample.net" rel=3D"noreferrer" target=
=3D"_blank">www.xample.net</a>=C2=A0 =C2=A0 =C2=A0 3600 IN CNAME cname.cdn-=
a.example<br>
=C2=A0 =C2=A0 cname.cdn-a.example 3600 IN A 192.0.2.1<br>
<br>
and<br>
<br>
=C2=A0 =C2=A0 <a href=3D"http://www.xample.net" rel=3D"noreferrer" target=
=3D"_blank">www.xample.net</a>=C2=A0 =C2=A0 =C2=A0 3600 IN CNAME cname.cdn-=
b.example<br>
=C2=A0 =C2=A0 cname.cdn-b.example 3600 IN HTTPSSVC 1 . alpn=3Dh3 esniconfig=
=3D&quot;...&quot;<br>
<br></blockquote><div><br></div><div>(You have two distinct CNAMEs for &quo=
t;<a href=3D"http://www.xample.net">www.xample.net</a>&quot; listed there.=
=C2=A0 Technically this is not allowed by the CNAME specification.=C2=A0 Ho=
wever, we can ignore that issue.)</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
My understanding is that in this case the client could end up connecting to=
<br>
192.0.2.1 (CDN A) with CDN B&#39;s ESNI config (or e.g. with the wrong ALPN=
).</blockquote><div><br></div><div>No, this is not possible.=C2=A0 When usi=
ng B&#39;s ESNI config, the only allowed IP addresses are those for cname.c=
dn-b.example.</div><div><br></div><div>In this case (as with any case where=
 SvcDomainName=3D&quot;.&quot;, IP hints would not provide a performance ad=
vantage, because HTTPSSVC is always queried in parallel with A/AAAA, so the=
 record for cname.cdn-b.example will come back along with the corresponding=
 IPs anyway.</div><div><br></div><div>...</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">9. Speaking of multi-CDN, AFAICT the problem is menti=
oned only once in the whole<br>
draft and only in relation to ESNI. However this is not ESNI-specific and a=
lso<br>
affects e.g. HTTP/3 as per the example above. So I think it would be useful=
 to<br>
go into a little more detail on this.<br></blockquote><div><br></div><div>O=
K, please suggest text.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">
10. Section B.2: s/pther/other/<br></blockquote><div><br></div><div>Will fi=
x.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Cheers<br>
<br>
[0] <a href=3D"https://github.com/rthalley/dnspython/pull/452" rel=3D"noref=
errer" target=3D"_blank">https://github.com/rthalley/dnspython/pull/452</a>=
<br>
<br>
_______________________________________________<br>
DNSOP mailing list<br>
<a href=3D"mailto:DNSOP@ietf.org" target=3D"_blank">DNSOP@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dnsop" rel=3D"noreferrer" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/dnsop</a><br>
</blockquote></div></div>

--0000000000008ca73805a3c1602f--

--00000000000097a9b005a3c1606b
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL
ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK
R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF
MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB
IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI
dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp
jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG
qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O
sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy
L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH
AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ
1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF
BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw
NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn
BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG
AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B
AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu
tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb
M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0
KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s
fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA
ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz
MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw
MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR
BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG
4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL
JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh
BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR
AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud
DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b
vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt
rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D
uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek
TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf
Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU
oAMCAQICEAGuEkclHdvQz4ddwMbsMFgwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX
BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx
ODAeFw0yMDAxMDcwODIyMjJaFw0yMDA3MDUwODIyMjJaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz
Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwrwIVY3rOZp1Papu
Yl53bMQ2H713K9788lbE9itKEL7tJAJO7GqZGRbfxPUVRRDYPntAf+j0JZZOvf9Ye6uN12SNW+v1
V0o5YeXtXMpNOkprr0v0v7qc80yhbq8RIIiX4usDJwuDGbcL/VKnlCTDPRp+VWUB8rkaqObapi/F
BGiPWXBqiT36W5opr6eJjUHuGiqzmK/1lCXMZSn6n3wkkbnonFsF5G4kfie+n/DDNd1hlqd06bzB
rCnToS+BV/Y9BroXiOjVWJnMe/8Rce7zA8Dzr0kU+gacBArnMiDyCvUGjngbASU7VaIPJBc/zBzI
L5QoeUAfgEJcGvFIEJUUIwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j
b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E
FgQU+WKCBtTdknJDbiAjMsikOsbLHoAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF
BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE
RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt
aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2
MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G
CSqGSIb3DQEBCwUAA4IBAQA2eHjHcJ8kaiqDQGv7TdNEBFiDI8omlzpnnuQFciHkWhkfi3mQwuuZ
IQIHd+JNpV0TQ8TqMNAr4YSPWOjwTd3UNxm+qghV3KC9j/Ygq39OzUlqxWv2lFH8mGFpbview2GI
xZWXTCRbeod3ZevhC0lOUVVx4NCHe5yWSwjEpZHUilSnjyqN7ssC0eYQBylFOf2xVxu1JB8Xewgw
Vk/DeOzsapxxjiuw2UZsDZbtVJvEx/C34GkACLR4Lm0k6O5ujAiDBkyy2nklxLhmKb9fyiH51B3j
oRE8y99FJOCHoye9E/P2tK12x9w9ZeF07eWAdX3OkhTne1DitwLidojuyFm9MYICYTCCAl0CAQEw
XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv
YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhABrhJHJR3b0M+HXcDG7DBYMA0GCWCGSAFlAwQCAQUAoIHU
MC8GCSqGSIb3DQEJBDEiBCBxBjUSK1YHccxArVnco+FzwNcewyKt1miRhhDT23gd7DAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA0MjAyMzM3MDhaMGkGCSqGSIb3
DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE
ggEAlsjbEBaAswex1vKeq6Nb2xaMtYZnXNkhRlgnZgIW2eYT7/BR6BW+8oToHvMXJeztn7Kj04oI
0DcFdyi9Y1FL/iizccmCdWvTUB+KXmzDqKPf6EhspcbCvD7Sx23QwOeM3i+MjtSBtJePZxbYbCDe
Uvsf8oGWZKQsVUYJUvgdgrnNFwK0m1D89tarDk6eLM9XHNXdTib8wGLuKu14e7JCV/A9kkJTq6vq
uFl3pEW0Sjxk2T68L8Bhto/0kfFn8FFIfVLNa6qvIp4TrmZrY7+a8hSeLMoUI8iWAzDqCaDB3J1p
rSHVDpBMB82nwsZ/AiOGeDCHT/38/MTdOqVKEQndsQ==
--00000000000097a9b005a3c1606b--