Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485413A1635 for ; Mon, 20 Apr 2020 20:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.699 X-Spam-Level: X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilKfTIMZNcib for ; Mon, 20 Apr 2020 20:02:15 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3A8B3A1633 for ; Mon, 20 Apr 2020 20:02:14 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id u13so14716981wrp.3 for ; Mon, 20 Apr 2020 20:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZqxAzWO/1Iia+8xdIfy6H2M1LYfhoEN7QVJ5Bzu3DGM=; b=f9PuMrzAG9ZcwXZY1iyN55wOzxvjoN0R+R3DQCMp1R84B7NeIfXPA2yjtsaB0fOGYP cK1hUOMU8AnjHjRp3SJBGO5+yCvleT71o49VbvMAjXn1RGnvK670Ezm8NPbAEsG/5Bmg 3SGO/yKxV4zdciookrLxC2m5fZoYnmqpF4qNuOMHo8R1i9oRnQm1TXoXaB8VYAaI1qkW GdWu3joTFe/yDEnzTSvMJ+6EF1NWi3V5Q9YA2s1uAwS3ka0XUjezW1M4cGR7KxLp5E/0 RtLHwPBpkuJugHKP+i0AZTH0Kzvpgska0PSLokBHq3uq1AJld42pCMmA4KJBKSdRmJ0V ESNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZqxAzWO/1Iia+8xdIfy6H2M1LYfhoEN7QVJ5Bzu3DGM=; b=aoEF6BSPC4jIj42rQ0AkRsgw0EY/IXICiHXmtjS6BMWUXoiBY7AUgLhqNDky8VfqaC XQEe9/cwCKMJdCuox8ki1gE4fixF7BpT+dfyb1oH3WjDVdzCyMvMsIOcGv8H9ZHRZIVi NOGwLfXv5ZpWWI2Vu4Q60RkAxYuysTksAzcsUjJDOkvg+dqVPhOBh1BHgVF1ZtUa2XMk zSwn7Zv1EmeMTT9BeWfVeO54E8jw01rEMHmjJnkvJmVX7Qua+fEJQUMwbFP18aR6Ruos NqvQQdj9eaYb+ajw1DyEH8M1TwLkK567baw6cx0qBevmP3C7uQRoy5uICDJhUYJLiLW+ apRQ== X-Gm-Message-State: AGi0PuZpKTg3FOx0TEe0BDhVc6n0TYqRZapOs9O2qbjPp3yRcDA1eCuX CwKGrD1bVh2fNaDK+UUQSVBYmjc1ihFt2P4TKgEPDSHV X-Google-Smtp-Source: APiQypJnMcdLojUdN8p9CxjxdnlNLgf2xEyiyw7rRy3Eig61PvmMBsxPqbBDxy3RPVC38x2PhkTc4gNYzfPoDevfils= X-Received: by 2002:a5d:610e:: with SMTP id v14mr21246951wrt.159.1587438132698; Mon, 20 Apr 2020 20:02:12 -0700 (PDT) MIME-Version: 1.0 References: <20200417101932.GA2035@wakko.flat11.house> In-Reply-To: From: Ben Schwartz Date: Mon, 20 Apr 2020 23:02:00 -0400 Message-ID: To: Eric Orth Cc: Alessandro Ghedini , dnsop Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000000910c305a3c43ebe" Archived-At: Subject: Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-httpssvc-02 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2020 03:02:19 -0000 --0000000000000910c305a3c43ebe Content-Type: multipart/alternative; boundary="00000000000000f01105a3c43ea4" --00000000000000f01105a3c43ea4 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 20, 2020 at 9:25 PM Eric Orth wrote: > > > On Mon, Apr 20, 2020 at 7:39 PM Ben Schwartz 40google.com@dmarc.ietf.org> wrote: > >> >> >> On Mon, Apr 20, 2020 at 7:30 PM Eric Orth > 40google..com@dmarc.ietf.org <40google.com@dmarc.ietf.org>> wrote: >> >>> >>> >>> 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. >>>> >>>> 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). >>>> >>>> 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. >>>> >>> >>> I think the stronger distinction makes it easier to describe the >>> required behavior differences. Much simpler to just say things like don't >>> mix both forms in the same response, and to ignore non-alias if any aliases >>> are present, than to make more detailed descriptions about what specific >>> optional contents are allowed to be mixed or not to accomplish the same >>> thing. >>> >>> >>>> >>>> 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 :) >>>> >>>> 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. >>>> >>>> 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, 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="..." >>>> >>>> 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). So if >>>> the server doesn't provide IP hints there would indeed be impact on >>>> performance >>>> because the client would just straight up fail to connect initially >>>> (e.g. maybe >>>> CDN A doesn't support HTTP/3, but CDN B's HTTPSSVC says the client can >>>> use it, >>>> or just because of the wrong ESNI config). >>>> >>>> Long story short, I don't think the text should discourage setting >>>> ipv4hint and >>>> ipv6hint here. I get that it's SHOULD NOT and not MUST NOT, but it's >>>> pretty >>>> confusing nevertheless. >>>> >>> >>> I don't think the hints are intended for this problem. I think the >>> general design idea is that A/AAAA are the definitive address results for a >>> given name, and clients can just optionally shortcut querying A/AAAA if >>> given hints. >>> >>> In your example, I believe the "." HTTPSSVC entry indicates that the >>> A/AAAA addresses for "cname.cdn-b.example" should be used, so it doesn't >>> seem like there is a multi-CDN problem. The correct addresses for the >>> correct CDN are used. >>> >>> But I think this might point out a potential problem with skipping hints >>> for "." results. If the HTTPSSVC result passes through a CNAME, a >>> non-HTTPSSVC-supporting recurssive will handle the CNAME, but not lookup >>> A/AAAA for the HTTPSSVC. >>> >> >> I don't think this can happen. Any CNAME that affects HTTPSSVC will also >> affect the corresponding A/AAAA queries, which are always issued >> simultaneously and to the same QNAME. >> > > alessandro@'s case was for multiple CNAME's and a recursive with behavior > that could follow those in different directions for the different > requests. Not technically legal, but the more important question here is > whether or not significant instances behave in this non-standard way. If > they do, this will lead to a situation where hints would be beneficial even > for "." records. > Thanks for the explanation. I would prefer to warn against this, rather than encourage more use of hints. When SvcDomainName is ".", I think not including hints is going to perform better on average, even in the case of multiple CNAMEs, because the split-CNAME cases should be very rare (due to caching), but the hints add overhead to every response. They can also impair load balancing if managed poorly. So does anybody know how common such non-standard behavior is? My 5-minute > research says that some versions of BIND allow round-robin between multiple > CNAME records. > > >> >> >>> So the client gets an HTTPSSVC result for cname.cdn-b.example but only >>> queried A/AAAA for www.xample.net, so without hints, the client will >>> have to do an extra set of A/AAAA queries for cname..cdn-b.example. >>> >>> >>>> >>>> 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. >>>> >>>> 10. Section B.2: s/pther/other/ >>>> >>>> Cheers >>>> >>>> [0] https://github.com/rthalley/dnspython/pull/452 >>>> >>>> _______________________________________________ >>>> DNSOP mailing list >>>> DNSOP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnsop >>>> >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >>> >> --00000000000000f01105a3c43ea4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Apr 20, 2020 at 9:25 PM Eric = Orth <ericorth=3D40google= .com@dmarc.ietf.org> wrote:


On Mon, Apr 20, 20= 20 at 7:39 PM Ben Schwartz <bemasc=3D40google.com@dmarc.ietf.org> wrote:
<= div dir=3D"ltr">

On Mon, Apr 20, 2020 at 7:30 PM Eric Orth <ericorth= =3D40googl= e..com@dmarc.ietf.org> wrote:


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 par= t of
the dnspython library [0] and I'd be interested in doing some interop t= esting
with other people's implementations.

I also have a few comments/questions about the draft, apologies if they hav= e
already been discussed in the past (haven't been following the draft fr= om the
start).

1. For interop testing purposes it would be very helpful if the draft liste= d
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 b= e helpful. In
my implementation I'm currently using "65481" for SVCB and &q= uot;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, immedia= tely
after the introduction). It might also be a good idea to just move the exam= ples
to an Appendix instead.

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 ES= NI draft
(so e.g. if ESNI ends up taking longer, this draft could be published witho= ut
having to wait for it).

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 tw= o
cases would simplify the draft a bit without sacrificing much, though I mig= ht
be missing something.

I think the stron= ger distinction makes it easier to describe the required behavior differenc= es.=C2=A0 Much simpler to just say things like don't mix both forms in = the same response, and to ignore non-alias if any aliases are present, than= to make more detailed descriptions about what specific optional contents a= re allowed to be mixed or not to accomplish the same thing.
=C2= =A0

5. Section 2.1.1 says

=C2=A0 =C2=A0The presentation format for SvcFieldValue is a whitespace-sepa= rated
=C2=A0 =C2=A0list of elements representing a key-value pair, with an absent= value
=C2=A0 =C2=A0or "=3D" indicating an empty value.

It took me longer than I'd like to admit to understand the "with a= n absent value
or "=3D" indicating an empty value" part. I'd suggest re= wording that paragraph to
something like:

=C2=A0 =C2=A0The presentation format for SvcFieldValue is a whitespace-sepa= rated list of
=C2=A0 =C2=A0key=3Dvalue pairs (e.g. "key123=3Dvalue1 keys456=3Dvalue2= "). When the value, or
=C2=A0 =C2=A0both the value and the "=3D" are omitted, the value = should be interpreted as
=C2=A0 =C2=A0being empty.

Or something better :)

6. In Section 2.2 it says (in reference to param field values):

=C2=A0 =C2=A0o=C2=A0 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 define= d
according to the corresponding SvcParamKey, and then reference section 6 fo= r
ths currently defined keys. The same applies for section 2.1.1 for the
presentation format.

7. Section 4.3 says:

=C2=A0 =C2=A0All DNS servers SHOULD treat the SvcParam portion of the SVCB = RR...

Should it be SvcFieldValue instead of SvcParam? "SvcParam" is not= mentioned
anywhere else.

8. Maybe I'm missing something, but the following sentence in Section 6= ....4 seems
wrong:

=C2=A0 =C2=A0When SvcDomainName is ".", server operators SHOULD N= OT include these hints,
=C2=A0 =C2=A0because they are unlikely to convey any performance benefit.
My understanding is that ipv4hint and ipv6hint are the way to solve the ESN= I
multi-CDN problem, so let's say I have "www.example.net" tha= t CNAMEs to both
"cname.cdn-a.example" and "cname.cdn-b.example". A clie= nt queries both A and
HTTPSVC concurrently for "www.example.net", and receives two ans= wers (the answer
to the A query points to CDN A, while the answer to HTTPSSVC points to CDN = B):

=C2=A0 =C2=A0 www.xample.net=C2=A0 =C2=A0 =C2=A0 3600 IN CNAME cname.cdn-= a.example
=C2=A0 =C2=A0 cname.cdn-a.example 3600 IN A 192.0.2.1

and

=C2=A0 =C2=A0 www.xample.net=C2=A0 =C2=A0 =C2=A0 3600 IN CNAME cname.cdn-= b.example
=C2=A0 =C2=A0 cname.cdn-b.example 3600 IN HTTPSSVC 1 . alpn=3Dh3 esniconfig= =3D"..."

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= ). So if
the server doesn't provide IP hints there would indeed be impact on per= formance
because the client would just straight up fail to connect initially (e.g. m= aybe
CDN A doesn't support HTTP/3, but CDN B's HTTPSSVC says the client = can use it,
or just because of the wrong ESNI config).

Long story short, I don't think the text should discourage setting ipv4= hint and
ipv6hint here. I get that it's SHOULD NOT and not MUST NOT, but it'= s pretty
confusing nevertheless.

I don't thi= nk the=C2=A0hints are intended for this problem.=C2=A0 I think the general = design idea is that A/AAAA are the definitive address results for a given n= ame, and clients can just optionally shortcut querying A/AAAA if given hint= s.

In your example, I believe the "." HT= TPSSVC entry indicates that the A/AAAA addresses for "cname.cdn-b.exam= ple" should be used, so it doesn't seem like there is a multi-CDN = problem.=C2=A0 The correct addresses for the correct CDN are used.

But I think this might point out a potential problem with = skipping hints for "." results.=C2=A0 If the HTTPSSVC result pass= es through a CNAME, a non-HTTPSSVC-supporting=C2=A0recurssive=C2=A0will han= dle the CNAME, but not lookup A/AAAA for the HTTPSSVC.

I don't think this can happen.=C2=A0 Any = CNAME that affects HTTPSSVC will also affect the corresponding A/AAAA queri= es, which are always issued simultaneously and to the same QNAME.

alessandro@'s case was for mul= tiple CNAME's and a recursive with behavior that could follow those in = different directions for the different requests.=C2=A0 Not technically lega= l, but the more important question here is whether or not significant insta= nces behave in this non-standard way.=C2=A0 If they do, this will lead to a= situation where hints would be beneficial even for "." records.<= br>

Thanks for the explan= ation.=C2=A0 I would prefer to warn against this, rather than encourage mor= e use of hints.=C2=A0 When SvcDomainName is ".", I think not incl= uding hints is going to perform better on average, even in the case of mult= iple CNAMEs, because the split-CNAME cases should be very rare (due to cach= ing), but the hints add overhead to every response.=C2=A0 They can also imp= air load balancing if managed poorly.

So does anybody know how common such non-standard behavior is? My 5-= minute research says that some versions of BIND allow round-robin between m= ultiple CNAME records.
=C2=A0
=C2=A0=
=C2=A0 So the client gets an HTTPSSVC result = for=C2=A0cname.cdn-b.example but only queried A/AAAA for=C2=A0www.xample.net, so without hints= , the client will have to do an extra set of A/AAAA queries for cname..cdn-= b.example.
=C2=A0

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 a= lso
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.

10. Section B.2: s/pther/other/

Cheers

[0] https://github.com/rthalley/dnspython/pull/452=

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--00000000000000f01105a3c43ea4-- --0000000000000910c305a3c43ebe 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 MC8GCSqGSIb3DQEJBDEiBCDlrwBJhJQUBkrgLX61jZP2WamvC+oz9oS96YmbOAODqTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA0MjEwMzAyMTNaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAi22CR55GlTqJLpkFt9L9mgMq0gVjhFEg+OSk22p+ZfqQ50P6bPuq9zr4AhQ5RQG36d+vUBG6 cjB2+Y816sQ/GMn9THFVNxVEOqk6582tDUZEMp2d4hF0l4k9cpl8PDVHag+5c7psleh8sYjZSzxC 0zuAhg0kdect1gzjP+yKQ5M6ZEmcsxDANH9rruvv4KfMPFv9EGleZedHuwWC5LvpdJZSmzhNobvr ovm8x4FBrsRCnzTBuoIoP5DWs/Gf5wAQsfE4uKS7ZfAeekhA9cUJgJDRY4Y7LYMs00fEwsFDwD50 FRnrmi1RB0h49TYVdUoQ3vp2W1vkWG58vwi8ZbIThQ== --0000000000000910c305a3c43ebe--