[OpenAFS] Red Hat EL Support Customers - Please open a support case for kafs in RHEL8
Jeffrey Altman
jaltman@auristor.com
Tue, 7 May 2019 13:37:53 -0400
--Apple-Mail-1F5AB807-74AE-4D44-A39F-3F3B1E2E3A54
Content-Type: multipart/alternative;
boundary=Apple-Mail-290C3FE4-BB6C-4CF9-9720-6FBF1F6132B6
Content-Transfer-Encoding: 7bit
--Apple-Mail-290C3FE4-BB6C-4CF9-9720-6FBF1F6132B6
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Gary,
As far as I am aware there is no final decision either way with regards to i=
nclusion of kafs in rhel8. There are several components that were not merge=
d into Linux mainline until after the 4.18 kernel on which rhel8.0 is based.=
These include not only AuriStorFS feature and openafs compatibility enhance=
ments to kafs but the new Linux mount API which provides namespace support t=
hat kafs leverages and namespacing for keyrings which is needed for filesyst=
em credential management on behalf of containers.
There is no business case for Red Hat to commit a ten year investment simply=
to support legacy AFS deployments. The justification for including kafs is=
to support functionality that will result in new deployments. That functio=
nality requires the new mount API, keyring namespacing, and even some featur=
es that have yet to be implemented in AuriStorFS. =20
The door is not closed. David Howells and the AuriStor team continue to fil=
l in the gaps. This week a request was filed to add /afs to the File Hiera=
rchy System (FHS). Inclusion in the FHS is required by some Linux Distributi=
ons before a new roof directory can be added to the distribution.
Jeffrey Altman
> On May 7, 2019, at 1:17 PM, Gary Gatling <gsgatlin@ncsu.edu> wrote:
>=20
> It looks like Red Hat decided no concerning kafs and RHEL. This makes me s=
ad since they couldn't even be bothered to tell us...
>=20
> [root@localhost ~]# modprobe kafs
> modprobe: FATAL: Module kafs not found in directory /lib/modules/4.18.0-80=
.el8.x86_64
> [root@localhost ~]# cat /etc/redhat-release=20
> Red Hat Enterprise Linux release 8.0 (Ootpa)
>=20
>=20
>> On Thu, Dec 6, 2018 at 6:33 PM Jeffrey Altman <jaltman@auristor.com> wrot=
e:
>> To all AuriStorFS licensees and OpenAFS users,
>>=20
>> After more than seventeen years of development led by David Howells, the
>> Linux kernel now includes a production ready AFS/AuriStorFS client
>> (kafs) and RX RPC protocol implementation (AF_RXRPC)[1]. These are not
>> add-ons. kafs and af_rxrpc are baked into the mainline kernel.
>>=20
>> Jonathan Billings has been building kafs enabled Fedora Core kernels via
>> COPR[1] since July[3]. Beginning with the 4.19 kernel, Fedora Core
>> kernels now ship with kafs and af_rxrpc enabled.
>>=20
>> It was my hope that Red Hat would include kafs and af_rxrpc in RHEL8
>> Beta as an experimental technology. Unfortunately, the RHEL8 Beta
>> announced on Nov 15th did not include either.
>>=20
>> Thankfully it is not too late to for kafs and af_rxrpc to be added
>> before a final release of RHEL8 but RHEL support customers must make the
>> case by registering for the RHEL8 Beta[4] and opening a Support Case[5].
>>=20
>> When opening a support case please specify:
>>=20
>> Product: Red Hat Enterprise Linux
>> Version: 8.0 Beta
>> Case Type: Feature / Enhancement Request
>> Hostname: hostname of the system on which RHEL8 beta was installed
>> Problem
>> Statement: Request inclusion of kafs
>> Case
>> Description; Explain why your organization uses AFS/AuriStorFS in
>> addition to RHEL support storage systems and how the
>> inclusion of kafs and af_rxrpc in RHEL8 will benefit
>> your organization.
>>=20
>> It is very important that the Case Description be specific to your
>> organization. Each organization's reasons for using AFS/AuriStorFS are
>> different just as each organization's use cases are different.
>>=20
>> If you are eligible, please attempt to open a support request by
>> December 11th. Although this is not a hard deadline, many individuals
>> will begin taking end of year vacation time the middle of next week.
>>=20
>> Frequently Asked Questions:
>>=20
>> 1. Is the kafs kernel module a replacement for the OpenAFS and
>> AuriStorFS kernel modules?
>>=20
>> The best way to think of kafs is that it is an alternative to the
>> AFS/AuriStorFS and OpenAFS clients. When kafs is provided as part of a
>> Linux distribution and it is enabled, it is not necessary to install any
>> of the OpenAFS or AuriStorFS client packages.
>>=20
>> 2. Is kafs compatible with IBM AFS, OpenAFS and AuriStorFS servers?
>>=20
>> Yes. kafs is compatible with IBM AFS 3.6 and all versions of OpenAFS
>> and AuriStorFS servers.
>>=20
>> 3. Does enabling kafs and af_rxrpc in RHEL8 prevent installation of
>> AuriStorFS or OpenAFS clients?
>>=20
>> No. Not only can the AuriStorFS kernel module be installed on Linux
>> kernels built with kafs and af_rxrpc but both AuriStorFS and kafs can be
>> enabled at the same time. Runtime choices have to be made to decide
>> which will service the /afs mount point, which will use port 7001/udp
>> for the callback service, etc. However, there is nothing that prevents
>> co-existence.
>>=20
>> OpenAFS developers will need to ensure compatibility with the latest
>> RHEL kernels and build configurations. It is likely that minor coding
>> adjustments will need to be implemented.
>>=20
>> 4. How does kafs/af_rxrpc performance compare to OpenAFS and AuriStorFS
>> clients?
>>=20
>> In many workflows the kafs/af_rxrpc client is faster and more efficient
>> than either OpenAFS or AuriStorFS clients. kafs/af_rxrpc are tightly
>> integrated into the Linux network stack and virtual file system layer.
>> There is significantly less overhead in the network stack (no double
>> buffering) and no global locks. Building the Linux kernel from source
>> in /afs with kafs is at least 30% faster than the AuriStorFS cache
>> manager without encryption.
>>=20
>> 5. Are there features that OpenAFS has that kafs does not?
>>=20
>> Yes. kafs does not split horizon caching, it does not have an
>> equivalent of cache bypass, it does not implement any of the rxdebug or
>> xstat_cm statistics collection. Nor does it provide pioctls and there is
>> no fs, vos, pts, bos command suite. kafs does not export afs2nfs.
>>=20
>> 6. Are there features that AuriStorFS has that kafs does not?
>>=20
>> In addition to the items mentioned in the prior answer, kafs does not
>> yet support the yfs-rxgk security class and aes256-cts-hmac-sha1-96 or
>> aes256-cts-hmac-sha512-384 encryption. O_DIRECT support is not yet
>> complete. kafs is a fairly complete AuriStorFS client including support
>> for IPv6 and AuriStorFS RPC suites.
>>=20
>> 7. Does kafs have capabilities that are implemented in neither OpenAFS
>> nor AuriStorS?
>>=20
>> kafs auto-mounts each afs volume as a separate device instead of
>> treating the entire /afs file namespace as a single device. kafs
>> implements speculative file status fetching from directory lookups.
>>=20
>> Perhaps more important is what kafs will be able to implement that
>> OpenAFS and AuriStorFS cannot due to GPL vs IPL10 license conflicts:
>>=20
>> * inotify notification event generation
>> * SELinux/Smack label storage
>> * better container namespacing
>>=20
>> 8. If my organization is happy with OpenAFS and/or AuriStorFS clients,
>> why should my organization care?
>>=20
>> Out-of-the-box Linux distribution support for accessing the /afs file
>> namespace will significantly simplify the lives of end users not to
>> mention system administrators and help desk support staff. When kafs is
>> distributed as part of the Linux kernel, there can never be a conflict
>> between the kernel version and the AFS kernel module since they are one
>> and the same. There can never be a delay between the availability of a
>> new kernel version and the matching OpenAFS or AuriStorFS kernel module.
>> AuriStor promises a new kernel module release within 48 hours of the
>> release of a kernel for a supported Linux distribution. With OpenAFS
>> there have been many circumstances when the delay has been measured in
>> weeks or months.
>>=20
>> Organizations that have support contracts with Linux vendors are often
>> told that support does not apply when the Linux kernel has been tainted
>> by a third-party kernel module. When using kafs, the Linux kernel is
>> never tainted.
>>=20
>> As part of the Linux kernel source tree, kafs is indirectly supported by
>> the entire Linux kernel development community. All of the automated
>> testing performed against the mainline kernel is also performed against
>> kafs. All kernel interface changes impacting kafs or af_rxrpc must be
>> implemented in kafs and af_rxrpc by the developer(s) promoting the
>> change. All-in-all kafs and af_rxrpc will receive reviews by a much
>> larger community of developers.
>>=20
>> Finally, as an out-of-the-box solution, /afs becomes a first class file
>> system namespace. As a result, AFS adoption will increase and /afs will
>> become accessible on systems that are managed by third-party such as
>> those in the cloud.
>>=20
>> 9. Is there anything I shouldn't say to Red Hat?
>>=20
>> Red Hat is going to make a business decision based upon its evaluation
>> of customer needs and their impact on growth of RHEL licensing. If I
>> were in their shoes I would not find a request to add support for kafs
>> compelling if it were combined with a statement that the requesting
>> organization intends to discontinue use of /afs within the next three to
>> five years. RHEL8 will have a support lifetime of at least a decade and
>> there is little justification to commit new engineering resources to a
>> technology that customers believe has no future.
>>=20
>> 10. Will AuriStor stop developing its own Linux client?
>>=20
>> No. AuriStor will always be able to ship new functionality in its own
>> clients first. AuriStor believes that kafs will be the AFS client for
>> 99.9% of end users with Linux desktops and servers. The AuriStorFS
>> client for Linux will be used by organizations that have special needs
>> and highly managed environments.
>>=20
>>=20
>> Thanks for your assistance on behalf of the entire AFS/AuriStorFS communi=
ty.
>>=20
>> Jeffrey Altman
>>=20
>>=20
>> [1] https://www.infradead.org/~dhowells/kafs/
>> [2] https://copr.fedorainfracloud.org/coprs/jsbillings/kafs/
>> [3] https://lists.openafs.org/pipermail/openafs-info/2018-July/042481.htm=
l
>> [4] https://developers.redhat.com/rhel8/getrhel8/
>> [5]
>> https://access.redhat.com/support/cases/#/case/new?intcmp=3Dhp%7Ca%7Ca3%7=
Ccase
>>=20
>>=20
--Apple-Mail-290C3FE4-BB6C-4CF9-9720-6FBF1F6132B6
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"></div><div dir=3D"ltr">Gar=
y,</div><div dir=3D"ltr"><br></div><div dir=3D"ltr">As far as I am aware the=
re is no final decision either way with regards to inclusion of kafs in rhel=
8. There are several components that were not merged into Linux mainli=
ne until after the 4.18 kernel on which rhel8.0 is based. These include not o=
nly AuriStorFS feature and openafs compatibility enhancements to kafs but th=
e new Linux mount API which provides namespace support that kafs leverages a=
nd namespacing for keyrings which is needed for filesystem credential manage=
ment on behalf of containers.</div><div dir=3D"ltr"><br></div><div dir=3D"lt=
r">There is no business case for Red Hat to commit a ten year investment sim=
ply to support legacy AFS deployments. The justification for including=
kafs is to support functionality that will result in new deployments.  =
;That functionality requires the new mount API, keyring namespacing, and eve=
n some features that have yet to be implemented in AuriStorFS. </div><=
div dir=3D"ltr"><br></div><div dir=3D"ltr">The door is not closed. Dav=
id Howells and the AuriStor team continue to fill in the gaps. This w=
eek a request was filed to add /afs to the File Hierarchy System (FHS). Incl=
usion in the FHS is required by some Linux Distributions before a new roof d=
irectory can be added to the distribution.</div><div dir=3D"ltr"><br></div><=
div dir=3D"ltr">Jeffrey Altman</div><div dir=3D"ltr"><br>On May 7, 2019, at 1=
:17 PM, Gary Gatling <<a href=3D"mailto:gsgatlin@ncsu.edu">gsgatlin@ncsu.=
edu</a>> wrote:<br><br></div><blockquote type=3D"cite"><div dir=3D"ltr"><=
div dir=3D"ltr"><div dir=3D"ltr">It looks like Red Hat decided no concerning=
kafs and RHEL. This makes me sad since they couldn't even be bothered to te=
ll us...<div><br></div><div><div>[root@localhost ~]# modprobe kafs</div><div=
>modprobe: FATAL: Module kafs not found in directory /lib/modules/4.18.0-80.=
el8.x86_64</div><div>[root@localhost ~]# cat /etc/redhat-release </div>=
<div>Red Hat Enterprise Linux release 8.0 (Ootpa)</div></div><div><br></div>=
</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_a=
ttr">On Thu, Dec 6, 2018 at 6:33 PM Jeffrey Altman <<a href=3D"mailto:jal=
tman@auristor.com">jaltman@auristor.com</a>> wrote:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
rgb(204,204,204);padding-left:1ex">To all AuriStorFS licensees and OpenAFS u=
sers,<br>
<br>
After more than seventeen years of development led by David Howells, the<br>=
Linux kernel now includes a production ready AFS/AuriStorFS client<br>
(kafs) and RX RPC protocol implementation (AF_RXRPC)[1]. These are not=
<br>
add-ons. kafs and af_rxrpc are baked into the mainline kernel.<br>
<br>
Jonathan Billings has been building kafs enabled Fedora Core kernels via<br>=
COPR[1] since July[3]. Beginning with the 4.19 kernel, Fedora Core<br>=
kernels now ship with kafs and af_rxrpc enabled.<br>
<br>
It was my hope that Red Hat would include kafs and af_rxrpc in RHEL8<br>
Beta as an experimental technology. Unfortunately, the RHEL8 Beta<br>
announced on Nov 15th did not include either.<br>
<br>
Thankfully it is not too late to for kafs and af_rxrpc to be added<br>
before a final release of RHEL8 but RHEL support customers must make the<br>=
case by registering for the RHEL8 Beta[4] and opening a Support Case[5].<br>=
<br>
When opening a support case please specify:<br>
<br>
Product: Red Hat Enterprise Linux<br>
Version: 8.0 Beta<br>
Case Type: Feature / Enhancement Request<br>
Hostname: hostname of the system on which RHEL8 bet=
a was installed<br>
Problem<br>
Statement: Request inclusion of kafs<br>
Case<br>
Description; Explain why your organization uses AFS/AuriStorFS i=
n<br>
addition to RHEL supp=
ort storage systems and how the<br>
inclusion of kafs and=
af_rxrpc in RHEL8 will benefit<br>
your organization.<br=
>
<br>
It is very important that the Case Description be specific to your<br>
organization. Each organization's reasons for using AFS/AuriStorFS are=
<br>
different just as each organization's use cases are different.<br>
<br>
If you are eligible, please attempt to open a support request by<br>
December 11th. Although this is not a hard deadline, many individuals<=
br>
will begin taking end of year vacation time the middle of next week.<br>
<br>
Frequently Asked Questions:<br>
<br>
1. Is the kafs kernel module a replacement for the OpenAFS and<br>
AuriStorFS kernel modules?<br>
<br>
The best way to think of kafs is that it is an alternative to the<br>
AFS/AuriStorFS and OpenAFS clients. When kafs is provided as part of a=
<br>
Linux distribution and it is enabled, it is not necessary to install any<br>=
of the OpenAFS or AuriStorFS client packages.<br>
<br>
2. Is kafs compatible with IBM AFS, OpenAFS and AuriStorFS servers?<br>
<br>
Yes. kafs is compatible with IBM AFS 3.6 and all versions of OpenAFS<b=
r>
and AuriStorFS servers.<br>
<br>
3. Does enabling kafs and af_rxrpc in RHEL8 prevent installation of<br>
AuriStorFS or OpenAFS clients?<br>
<br>
No. Not only can the AuriStorFS kernel module be installed on Linux<br=
>
kernels built with kafs and af_rxrpc but both AuriStorFS and kafs can be<br>=
enabled at the same time. Runtime choices have to be made to decide<br=
>
which will service the /afs mount point, which will use port 7001/udp<br>
for the callback service, etc. However, there is nothing that prevents=
<br>
co-existence.<br>
<br>
OpenAFS developers will need to ensure compatibility with the latest<br>
RHEL kernels and build configurations. It is likely that minor coding<=
br>
adjustments will need to be implemented.<br>
<br>
4. How does kafs/af_rxrpc performance compare to OpenAFS and AuriStorFS<br>
clients?<br>
<br>
In many workflows the kafs/af_rxrpc client is faster and more efficient<br>
than either OpenAFS or AuriStorFS clients. kafs/af_rxrpc are tightly<b=
r>
integrated into the Linux network stack and virtual file system layer.<br>
There is significantly less overhead in the network stack (no double<br>
buffering) and no global locks. Building the Linux kernel from source<=
br>
in /afs with kafs is at least 30% faster than the AuriStorFS cache<br>
manager without encryption.<br>
<br>
5. Are there features that OpenAFS has that kafs does not?<br>
<br>
Yes. kafs does not split horizon caching, it does not have an<br>
equivalent of cache bypass, it does not implement any of the rxdebug or<br>
xstat_cm statistics collection. Nor does it provide pioctls and there is<br>=
no fs, vos, pts, bos command suite. kafs does not export afs2nfs.<br>
<br>
6. Are there features that AuriStorFS has that kafs does not?<br>
<br>
In addition to the items mentioned in the prior answer, kafs does not<br>
yet support the yfs-rxgk security class and aes256-cts-hmac-sha1-96 or<br>
aes256-cts-hmac-sha512-384 encryption. O_DIRECT support is not yet<br>=
complete. kafs is a fairly complete AuriStorFS client including suppor=
t<br>
for IPv6 and AuriStorFS RPC suites.<br>
<br>
7. Does kafs have capabilities that are implemented in neither OpenAFS<br>
nor AuriStorS?<br>
<br>
kafs auto-mounts each afs volume as a separate device instead of<br>
treating the entire /afs file namespace as a single device. kafs<br>
implements speculative file status fetching from directory lookups.<br>
<br>
Perhaps more important is what kafs will be able to implement that<br>
OpenAFS and AuriStorFS cannot due to GPL vs IPL10 license conflicts:<br>
<br>
* inotify notification event generation<br>
* SELinux/Smack label storage<br>
* better container namespacing<br>
<br>
8. If my organization is happy with OpenAFS and/or AuriStorFS clients,<br>
why should my organization care?<br>
<br>
Out-of-the-box Linux distribution support for accessing the /afs file<br>
namespace will significantly simplify the lives of end users not to<br>
mention system administrators and help desk support staff. When kafs i=
s<br>
distributed as part of the Linux kernel, there can never be a conflict<br>
between the kernel version and the AFS kernel module since they are one<br>
and the same. There can never be a delay between the availability of a=
<br>
new kernel version and the matching OpenAFS or AuriStorFS kernel module.<br>=
AuriStor promises a new kernel module release within 48 hours of the<b=
r>
release of a kernel for a supported Linux distribution. With OpenAFS<b=
r>
there have been many circumstances when the delay has been measured in<br>
weeks or months.<br>
<br>
Organizations that have support contracts with Linux vendors are often<br>
told that support does not apply when the Linux kernel has been tainted<br>
by a third-party kernel module. When using kafs, the Linux kernel is<b=
r>
never tainted.<br>
<br>
As part of the Linux kernel source tree, kafs is indirectly supported by<br>=
the entire Linux kernel development community. All of the automated<br=
>
testing performed against the mainline kernel is also performed against<br>
kafs. All kernel interface changes impacting kafs or af_rxrpc must be<=
br>
implemented in kafs and af_rxrpc by the developer(s) promoting the<br>
change. All-in-all kafs and af_rxrpc will receive reviews by a much<br=
>
larger community of developers.<br>
<br>
Finally, as an out-of-the-box solution, /afs becomes a first class file<br>
system namespace. As a result, AFS adoption will increase and /afs wil=
l<br>
become accessible on systems that are managed by third-party such as<br>
those in the cloud.<br>
<br>
9. Is there anything I shouldn't say to Red Hat?<br>
<br>
Red Hat is going to make a business decision based upon its evaluation<br>
of customer needs and their impact on growth of RHEL licensing. If I<b=
r>
were in their shoes I would not find a request to add support for kafs<br>
compelling if it were combined with a statement that the requesting<br>
organization intends to discontinue use of /afs within the next three to<br>=
five years. RHEL8 will have a support lifetime of at least a decade an=
d<br>
there is little justification to commit new engineering resources to a<br>
technology that customers believe has no future.<br>
<br>
10. Will AuriStor stop developing its own Linux client?<br>
<br>
No. AuriStor will always be able to ship new functionality in its own<=
br>
clients first. AuriStor believes that kafs will be the AFS client for<=
br>
99.9% of end users with Linux desktops and servers. The AuriStor=
FS<br>
client for Linux will be used by organizations that have special needs<br>
and highly managed environments.<br>
<br>
<br>
Thanks for your assistance on behalf of the entire AFS/AuriStorFS community.=
<br>
<br>
Jeffrey Altman<br>
<br>
<br>
[1] <a href=3D"https://www.infradead.org/~dhowells/kafs/" rel=3D"noreferrer"=
target=3D"_blank">https://www.infradead.org/~dhowells/kafs/</a><br>
[2] <a href=3D"https://copr.fedorainfracloud.org/coprs/jsbillings/kafs/" rel=
=3D"noreferrer" target=3D"_blank">https://copr.fedorainfracloud.org/coprs/js=
billings/kafs/</a><br>
[3] <a href=3D"https://lists.openafs.org/pipermail/openafs-info/2018-July/04=
2481.html" rel=3D"noreferrer" target=3D"_blank">https://lists.openafs.org/pi=
permail/openafs-info/2018-July/042481.html</a><br>
[4] <a href=3D"https://developers.redhat.com/rhel8/getrhel8/" rel=3D"norefer=
rer" target=3D"_blank">https://developers.redhat.com/rhel8/getrhel8/</a><br>=
[5]<br>
<a href=3D"https://access.redhat.com/support/cases/#/case/new?intcmp=3Dhp%7C=
a%7Ca3%7Ccase" rel=3D"noreferrer" target=3D"_blank">https://access.redhat.co=
m/support/cases/#/case/new?intcmp=3Dhp%7Ca%7Ca3%7Ccase</a><br>
<br>
<br>
</blockquote></div>
</div></blockquote></body></html>=
--Apple-Mail-290C3FE4-BB6C-4CF9-9720-6FBF1F6132B6--
--Apple-Mail-1F5AB807-74AE-4D44-A39F-3F3B1E2E3A54
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Disposition: attachment;
filename=smime.p7s
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBdYw
ggXSMIIEuqADAgECAhBAAWbTGehnfUuu91hYwM5DMA0GCSqGSIb3DQEBCwUAMDoxCzAJBgNVBAYT
AlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEyMB4XDTE4MTEw
MjA2MjYyMloXDTE5MTEwMjA2MjYyMlowcDEvMC0GCgmSJomT8ixkAQETH0EwMTQyN0UwMDAwMDE2
NkQzMTlFODFBMDAwMDdBN0IxGTAXBgNVBAMTEEplZmZyZXkgRSBBbHRtYW4xFTATBgNVBAoTDEF1
cmlTdG9yIEluYzELMAkGA1UEBhMCVVMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDq
EYwjLORE23Gc8m7YgKqbGzWn/fmVGtoZkBNwOEYlrFOu84PbEhV4sxQrChhPyXVW2jquV2rg2/5d
sVC8RO+RwlXuAkUvR9KhWJLu6GJXwUnZr83wtEzJ8nqpTHj6W+3velLwWx7qhADyrMnKN0bTYh+5
M9HWt2We4qYi6i1/ejgKtM0arWYxVx6Iwb4xZpilMDNqV15Dwuunnkq4vNEByIT81zDoClqylMxx
KJpvc3tqC66+BHHM5RxF+z36Pt8fb3Q54VrytxXFm+kVSclKGaWgjq5SqV4tR0FWv6OnMY8tAx1Y
rljfvgxW5npZgBbo+YVoYEfUrz77WIYQyzn7AgMBAAGjggKcMIICmDAOBgNVHQ8BAf8EBAMCBPAw
gYQGCCsGAQUFBwEBBHgwdjAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2NzcC5pZGVu
dHJ1c3QuY29tMEIGCCsGAQUFBzAChjZodHRwOi8vdmFsaWRhdGlvbi5pZGVudHJ1c3QuY29tL2Nl
cnRzL3RydXN0aWRjYWExMi5wN2MwHwYDVR0jBBgwFoAUpHPa72k1inXMoBl7CDL4a4nkQuwwCQYD
VR0TBAIwADCCASsGA1UdIASCASIwggEeMIIBGgYLYIZIAYb5LwAGAgEwggEJMEoGCCsGAQUFBwIB
Fj5odHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5k
ZXguaHRtbDCBugYIKwYBBQUHAgIwga0agapUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJl
ZW4gaXNzdWVkIGluIGFjY29yZGFuY2Ugd2l0aCBJZGVuVHJ1c3QncyBUcnVzdElEIENlcnRpZmlj
YXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL3NlY3VyZS5pZGVudHJ1c3QuY29tL2NlcnRpZmlj
YXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDBFBgNVHR8EPjA8MDqgOKA2hjRodHRwOi8vdmFsaWRh
dGlvbi5pZGVudHJ1c3QuY29tL2NybC90cnVzdGlkY2FhMTIuY3JsMB8GA1UdEQQYMBaBFGphbHRt
YW5AYXVyaXN0b3IuY29tMB0GA1UdDgQWBBQevV8IqWfIUNkQqAugGhxR938z+jAdBgNVHSUEFjAU
BggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAKsUkshF6tfL43itTIVy9vjY
qqPErG9n8kX5FlRYbtIVlWIYTxQpeqtDpUPur1jfBiNY+xT+9PayO2+XxXu9ZEykCz5T4+3q7s5t
5RLsHu1dxYcMnAgfUqb13mhZxY8PVPE4PTHSvZLjPZ6Nt7j0tXjddZJqjDhr7neNpmYgQWSe+oaI
xbUqQ34rVW/hDimv9Y2DnCXL0LopCfABQDK9HDzmsuXdbVH6LUpS6ncge9kQEh1QIGuwqEv2tHCW
eauWM6h3BOXj3dlfbJEawUYz2hvc3nSXpscFlCN5tGAyUAE8QbKnH1ha/zZVrJY1EglFhnDho34l
Wl35t7pE5NP4kscxggKmMIICogIBATBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1
c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEyAhBAAWbTGehnfUuu91hYwM5DMA0GCWCGSAFlAwQC
AQUAoIIBKTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTA1MDcx
NzM3NTNaMC8GCSqGSIb3DQEJBDEiBCAsV+8FoftHAvFcq27hgifV2+/Ep5iYzqOQEl9kyG/B0zBd
BgkrBgEEAYI3EAQxUDBOMDoxCzAJBgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNV
BAMTDlRydXN0SUQgQ0EgQTEyAhBAAWbTGehnfUuu91hYwM5DMF8GCyqGSIb3DQEJEAILMVCgTjA6
MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEEx
MgIQQAFm0xnoZ31LrvdYWMDOQzANBgkqhkiG9w0BAQEFAASCAQBUratQuSVLA0+mrpgzzGjkXiol
Q1o7Mc4hmdSuxKi+i23PJKybzdPGbpCAg7Qa3iVN2/vhlzOd+nuYseI5+iT4puyU/T6R4Ijb0aSK
/jt4KkU1ISene+VhY7r2QYY/qW2sY+V/7Q/NVIQKDW7bhl7cOXZ1GUji3cwiPBgenWi4QuM558A2
1I48vMvM52ti059iVegAHyPO8keSaLthsplxE5ecLIqkDC6fWyPvXUsBQM6plsiikzp7LDt9ET+R
hZkVqiusaNWtTK3xBRgLGN58ZSB0ST7wwmx7O2StcKzAHVab8iApKXtTyvFyWgEbtgA1JTpZHBl2
H9aTJ7Wow8tGAAAAAAAA
--Apple-Mail-1F5AB807-74AE-4D44-A39F-3F3B1E2E3A54--