Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC0A129766 for ; Wed, 12 Oct 2016 07:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign-com.20150623.gappssmtp.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 2kYgbf_5uqZp for ; Wed, 12 Oct 2016 07:27:16 -0700 (PDT) Received: from mail-qt0-x263.google.com (mail-qt0-x263.google.com [IPv6:2607:f8b0:400d:c0d::263]) (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 97B9C1295D8 for ; Wed, 12 Oct 2016 07:27:13 -0700 (PDT) Received: by mail-qt0-x263.google.com with SMTP id m5so4890436qtb.0 for ; Wed, 12 Oct 2016 07:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=MYlluiyNdsnPEpaBbgFg4H2q0qBETdEiISIeXt6HKOU=; b=aMquYIOQQvqSeML/6EnGvEs8JhQF9f9DTdN/rO3YmPJlpi1QrLgt/sJ0+upqGEZ9TW Pllz3i0v7/Qv6x1LoTvbusVhWrZ7PE4iQnAYF30nCbckJI7uyojrENU+FbsaDUgnV479 +wOIvkzCSz7J+T0Bq+udZOvQXiK0hq41ZM9pVMcKX5q79cSqsxSieB47Fg+4a8XHP1J3 7JsRDOxXB0YbMmN6MlOcns66Hzh0ieLr7QM4qY/LuS1VTYCeK+sjg1n9wHLxaUEZ0ozV A++q5Hk1+X0oazTD0K1Qveusj28EESUmGb/XhIoXozowOK5ZpSCPjYuB2fslfJu+E6XX 1/TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=MYlluiyNdsnPEpaBbgFg4H2q0qBETdEiISIeXt6HKOU=; b=k5EROxpRvVlv4o/ZswUpcWmaMSKkObAzsgLzkVK3xHSfy2l7mwGeLkeDw0mk0W0/Vt iwHloiLAI5oAoz4SWAUiYdz5Q0wCIUQEC73PgJJ/YgED45YZsXVjxgusZGg21+Z7mQJa AKkww33zPzkGWwc+frqD9Pxow2Z9c0iDGTl/Dn7WE2/kw7UwOBR2SZWz8nGdMo3Zn9P/ v1UrnqJ344yLsiz1mqqpLEX3lsiP256QLChJ4pPqhpUXW4XhuMNkaY/B/IH/4eBo5pNC 4ma2bGiK8/yGI5DULXASaSd5FSG4SlcYMqoC2IYvKj1ia+MnA0EYphWc2TTM3DHIhmJU EQCA== X-Gm-Message-State: AA6/9RnMtcPktQH3XBqvdzno6PzhYRhcqsIMS4Gm9seyOvB3sc71ojnqFFjjQQGWwd3QxB1FCln7ZS6LqJM4z/7GvSHhrDE0 X-Received: by 10.237.60.116 with SMTP id u49mr1437623qte.47.1476282430378; Wed, 12 Oct 2016 07:27:10 -0700 (PDT) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id k38sm1111043qkh.2.2016.10.12.07.27.10 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 12 Oct 2016 07:27:10 -0700 (PDT) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id u9CER91F025024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Oct 2016 10:27:09 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Wed, 12 Oct 2016 10:27:06 -0400 From: "Gould, James" To: Robert Sparks Thread-Topic: Gen-art LC (and telechat) review for draft-ietf-regext-epp-rdap-status-mapping-01 Thread-Index: AQHSH0s0QR2PphM9rkml+sbHfJkdnqCiGmkAgAGbUICAAXgkAA== Date: Wed, 12 Oct 2016 14:27:05 +0000 Message-ID: <9FB1EC12-06CF-4696-9010-2C37C41EEC4C@verisign.com> References: <1016282d-9f98-fc86-572d-ca80c10db3a5@nostrum.com> <94AC877C-EE87-4425-8E00-95965F945BA1@verisign.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; boundary="Apple-Mail=_016785F7-70FE-427A-81E5-35832C21DEE5"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Cc: General Area Review Team , "ietf@ietf.org" , regext , "draft-ietf-regext-epp-rdap-status-mapping.all@ietf.org" Subject: Re: [Gen-art] Gen-art LC (and telechat) review for draft-ietf-regext-epp-rdap-status-mapping-01 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 14:27:20 -0000 --Apple-Mail=_016785F7-70FE-427A-81E5-35832C21DEE5 Content-Type: multipart/alternative; boundary="Apple-Mail=_68015AA2-B0FE-4DFA-8E3A-F1B498CAE215" --Apple-Mail=_68015AA2-B0FE-4DFA-8E3A-F1B498CAE215 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Robert, Thanks again for reviewing the draft and providing feedback. I reply to = your replies below. =20 =E2=80=94 JG James Gould Distinguished Engineer jgould@Verisign.com = 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com > On Oct 11, 2016, at 12:00 PM, Robert Sparks = wrote: >=20 > Responses inline - >=20 > On 10/10/16 10:28 AM, Gould, James wrote: >> Robert, >>=20 >> Thank you for your review and feedback. I provide responses to your = feedback below. >>=20 >> =E2=80=94 >>=20 >> JG >>=20 >>=20 >> >>=20 >> James Gould >> Distinguished Engineer >> jgould@Verisign.com >>=20 >> 703-948-3271 >> 12061 Bluemont Way >> Reston, VA 20190 >>=20 >> VerisignInc.com >>> On Oct 5, 2016, at 4:58 PM, Robert Sparks > wrote: >>>=20 >>> I am the assigned Gen-ART reviewer for this draft. The General Area >>> Review Team (Gen-ART) reviews all IETF documents being processed >>> by the IESG for the IETF Chair. Please treat these comments just >>> like any other last call comments. >>>=20 >>> For more information, please see the FAQ at >>>=20 >>> >. >>>=20 >>> Document: draft-ietf-regext-epp-rdap-status-mapping-01 >>> Reviewer: Robert Sparks >>> Review Date: 5 Oct 2016 >>> IETF LC End Date: 10 Oct 2016 >>> IESG Telechat date: 13 Oct 2016 >>>=20 >>> Summary: This draft is on the right track but has open issues, = described in the review. >>>=20 >>> Major Issue: >>>=20 >>> Many of the descriptions describe only side-effects of the status = instead of the status itself. >>>=20 >>> All of the descriptions for the new rdap status codes start with = "For DNR that indicates". This implies that there is a "For not DNR" = case that's not discussed. I don't think the phrase is necessary and = each description should look more like the other descriptions already = registered at = http://www.iana.org/assignments/rdap-json-values/rdap-json-values.xhtml = .= >>>=20 >>> For instance, at 'auto renew period' the document currently says: >>>=20 >>> "For DNR that indicates if the object is deleted by the registrar = during this period, the registry provides a credit to the registrar for = the cost of the auto renewal" >>>=20 >>> That discusses something (and not the only thing) that can happen = while the object is in that state. It does not describe the state. >>>=20 >>> I suggest it should instead say (based on the text in 3915 and the = current registry entry style): >>>=20 >>> "The object instance is in a grace period provided between when its = registration period expires and when its registration is automatically = renewed by the registry." >>>=20 >>> I don't think it's important to include the commentary about = providing a credit if the entity is deleted by the registrar during this = period, but since that commentary exists in 3915, you can include it if = you want. The _important_ part to convey is the actual status. >>=20 >>=20 >> The =E2=80=9CFor DNR that indicates=E2=80=9D can be removed from the = descriptions. For example, the "addPeriod =3D add period; For DRN that = indicates if the object is =E2=80=A6=E2=80=9D mapping could be = "addPeriod =3D add period; If the object is =E2=80=A6=E2=80=9D. The = purpose of this draft is to map the statuses defined in EPP and RDAP, so = the status descriptions included in the draft where taken from the EPP = RFC=E2=80=99s. There is no intent to redefine the statuses included in = the EPP RFC=E2=80=99s in anyway. > But you are not including the entire EPP definition for most of these = - you are only copying in _part_ of it, and it's not the important part. > Looking at -02 of the draft, you currently have this: >=20 > addPeriod =3D add period; If the object is deleted by the client > during this period, the server provides a credit to the client > for the cost of the registration. > Where did you take the definition out of the EPP suite though? > On a fast skim, I assumed you took it from this statement in RFC3915: >=20 > addPeriod: This grace period is provided after the initial > registration of a domain name. If the domain name is deleted by > the registrar during this period, the registry provides a credit > to the registrar for the cost of the registration. >=20 >=20 > You left out "The grace period is provided after the initial = registration of a domain name" which is what the the status _is_. That's = what the status code is conveying. The extra words about credit after = deletion are commentary about things that can happen while the object is = in that state. >=20 > (And you're already changing words by using "the client" instead of = "the registrar".) >=20 > Maybe you took the state definition from some other place? >=20 > Many of the other definitions in this document have that same problem. Yes, this is the text block from RFC 3915 that was used as the basis for = the description. I disagree that the extra words about credit after = deletion are commentary, since that is really the point of the status. = The status does not do anything other than to inform the client / = registrar that a credit will be given upon deletion. I can add the = =E2=80=9CThis grace period is provided after the initial registration of = a object=E2=80=9D and look to add similar text to the other statuses. = Does that meet your concern? =20 The reason for the change in the terms (object instead of domain name, = client instead of registrar, and server instead of registry) is based on = your prior feedback of not tying the statuses to the Domain Name = Registries (DNR). Does providing more generic descriptions make sense = to you? =20 >=20 >>=20 >>>=20 >>> All of the descriptions will need similar attention. Some of them = (such as clientUpdateProhibited) currently have 2119 words in the = description. That doesn't make sense - this is a status, not an protocol = instruction, and trying to put normative language in a registry will = lead to confusion about where the behavior you are trying to describe is = actually defined. (To be fair, 5731 has this same problem). Again, I = suggest following the style that's already in the registry and say = something like "The client has requested that any requests to update = this object instance be rejected." >>>=20 >>>=20 >>=20 >> The clientUpdateProhibited status is defined as: >>=20 >> clientUpdateProhibited =3D client update prohibited; For DNR that >> indicates the client requested that requests to update the = object >> (other than to remove this status) MUST be rejected. >>=20 >> Where do you see 2119 words in the clientUpdateProhibited = description? The status descriptions were taken from the EPP RFC=E2=80=99= s with no intent on changing their meaning. =20 > You copied it - above - it's the MUST.=20 > This is 5731's issue - that MUST should have been in text about what = servers do with requests received while the object is in that state, = instead of being part of the state definition, and the state description = in a registry. > I understand not wanting to risk introducting confusion by restating a = definition since you are simply wanting to take the EPP definitions = completely, so it's probably the better trade-off to propagate that = problem rather than fix it in this document.=20 >=20 Got it, thanks. >>> Minor Issues: >>>=20 >>> You're setting up a minor maintenance headache for any future work = that might update this document by having the descriptions listed in two = places. I don't think it's necessary to list the descriptions in section = 2 (currently the bulk of page 4 and the beginning of page 5). Instead, = stop after the paragraph that ends at the top of page 4, and note that = the descriptions of each new status code are provided in section 3. >>=20 >> The desire was for section 2 to stand on its own to define the = statuses and the mapping, and for section 3 to be used to register the = statuses in registry. I believe it would be cleaner to duplicate the = descriptions in this instance. =20 > As I note, this is a minor issue, but I disagree. Cleaner for _who_? = It's certainly not cleaner for the anyone who has to revise this = document (and it's not cleaner for you as the editor of this document or = the RFC editor since you have to make any change in two places, risking = having the document become internally inconsistent). I don't see how = it's cleaner for the implementer of the specification either. >=20 We can agree to disagree on this one. It is cleaner for the user of the = document. As the editor of the document, it=E2=80=99s not an issue. = Section 2 provides the description of the mapping and section 3 is for = IANA consideration to get the missing statuses registered into RDAP JSON = Values Registry. =20 >=20 >>>=20 >>> Nits: >>>=20 >>> Near the end of page 3, the document says "In the DNR, the client = and server prohibited statuses are separate an RDAP MUST support the = same separation." There are several nits to address with this. That MUST = is not a good use of 2119. DNR hasn't been expanded (and "the DNR" is = not particularly clear). >>>=20 >>> I suggest you replace that sentence, and the one immediately before = it with: >>>=20 >>> "EPP provides status codes that allow distinguishing the case that = an action is prohibited because of server policy from the case that an = action is prohibited because of a client request. The ability to make = this distinction needs to be preserved in RDAP.=E2=80=9D >>>=20 >>=20 >> This change will be made. =20 >>=20 >>>=20 >>=20 >=20 --Apple-Mail=_68015AA2-B0FE-4DFA-8E3A-F1B498CAE215 Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_450D0328-09F8-4BEB-9CA1-7EA8294D2C59" --Apple-Mail=_450D0328-09F8-4BEB-9CA1-7EA8294D2C59 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Robert,

Thanks again for reviewing the draft and providing feedback. =  I reply to your replies below.  

=E2=80=94


JG




James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont = Way
Reston, VA 20190

VerisignInc.com

On Oct 11, 2016, at 12:00 PM, Robert Sparks <rjsparks@nostrum.com> wrote:

=20

Responses inline -


On 10/10/16 10:28 AM, Gould, James wrote:
=20 Robert,

Thank you for your review and feedback.  I = provide responses to your feedback below.

=E2=80=94

JG


<Mail = Attachment.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com

On Oct 5, 2016, at 4:58 PM, Robert Sparks = <rjsparks@nostrum.com> wrote:

I am the assigned Gen-ART reviewer for = this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
=
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>= .

Document: = draft-ietf-regext-epp-rdap-status-mapping-01
Reviewer: Robert Sparks
Review Date: 5 Oct 2016
IETF LC End Date: 10 Oct 2016
IESG Telechat date: 13 Oct 2016

Summary: This draft is on the right track but has open issues, described in the review.

Major Issue:

Many of the descriptions describe only side-effects of the status instead of the status itself.

All of the descriptions for the new rdap status codes start with "For DNR that indicates". This implies that there is a "For not DNR" case that's not discussed. I don't think the phrase is necessary and each description should look more like the other descriptions already registered at http://www.iana.org/assignments/rdap-json-values/rdap-json-valu= es.xhtml.

For instance, at 'auto renew period' the document currently says:

"For DNR that indicates if the object is deleted by the registrar during this period, the registry provides a credit to the registrar for the cost of the auto renewal"

That discusses something (and not the only thing) that can happen while the object is in that state. It does not describe the state.

I suggest it should instead say (based on the text in 3915 and the current registry entry style):
=
"The object instance is in a grace period provided between when its registration period expires and when its registration is automatically renewed by the registry."

I don't think it's important to include the commentary about providing a credit if the entity is deleted by the registrar during this period, but since that commentary exists in 3915, you can include it if you want. The _important_ part to convey is the actual status.


The =E2=80=9CFor DNR that indicates=E2=80=9D = can be removed from the descriptions.  For example, the "addPeriod =3D add = period; For DRN that indicates if the object is =E2=80=A6=E2=80=9D =  mapping could be "addPeriod =3D add period; If the object is =E2=80=A6=E2=80= =9D.  The purpose of this draft is to map the statuses defined in EPP and RDAP, so the status descriptions included in the draft where taken from the EPP RFC=E2=80=99s.  There = is no intent to redefine the statuses included in the EPP RFC=E2=80=99s = in anyway.
But you are not including the entire EPP definition for most of these - you are only copying in _part_ of it, and it's not the important part.
Looking at -02 of the draft, you currently have this:

=20 
   addPeriod =3D add period;  If the object is =
deleted by the client
       during this period, the server provides a credit to the client
       for the cost of the registration.
Where did you take the definition out of the EPP suite though?
On a fast skim, I assumed you took it from this statement in RFC3915:

=20 
   addPeriod: This grace period is provided after =
the initial
      registration of a domain name.  If the domain name is deleted by
      the registrar during this period, the registry provides a credit
      to the registrar for the cost of the registration.

You left out "The grace period is provided after the initial registration of a domain name" which is what the the status _is_. That's what the status code is conveying. The extra words about credit after deletion are commentary about things that can happen while the object is in that state.

(And you're already changing words by using "the client" instead of "the registrar".)

Maybe you took the state definition from some other place?

Many of the other definitions in this document have that same problem.

Yes, this is the text block from RFC 3915 that was = used as the basis for the description.  I disagree that the extra = words about credit after deletion are commentary, since that is really = the point of the status.  The status does not do anything other = than to inform the client / registrar that a credit will be given upon = deletion.  I can add the =E2=80=9CThis grace period is provided = after the initial registration of a object=E2=80=9D and look to add = similar text to the other statuses.  Does that meet your concern? =  

The reason for the change in = the terms (object instead of domain name, client instead of registrar, = and server instead of registry) is based on your prior feedback of not = tying the statuses to the Domain Name Registries (DNR).  Does = providing more generic descriptions make sense to you? =  





All of the descriptions will need similar attention. Some of them (such as clientUpdateProhibited) currently have 2119 words in the description. That doesn't make sense - this is a status, not an protocol instruction, and trying to put normative language in a registry will lead to confusion about where the behavior you are trying to describe is actually defined. (To be fair, 5731 has this same problem). Again, I suggest following the style that's already in the registry and say something like "The client has requested that any requests to update this object instance be rejected."



The clientUpdateProhibited status is defined = as:

clientUpdateProhibited =3D client update =
prohibited;  For DNR that
       indicates the client requested that requests to update the object
       (other than to remove this status) MUST be rejected.

Where do you see 2119 words in the = clientUpdateProhibited description?  The status descriptions were taken from = the EPP RFC=E2=80=99s with no intent on changing their = meaning. 
You copied it - above - it's the MUST.
This is 5731's issue - that MUST should have been in text about what servers do with requests received while the object is in that state, instead of being part of the state definition, and the state description in a registry.
I understand not wanting to risk introducting confusion by restating a definition since you are simply wanting to take the EPP definitions completely, so it's probably the better trade-off to propagate that problem rather than fix it in this document.


Got it, thanks.

Minor Issues:

You're setting up a minor maintenance headache for any future work that might update this document by having the descriptions listed in two places. I don't think it's necessary to list the descriptions in section 2 (currently the bulk of page 4 and the beginning of page 5). Instead, stop after the paragraph that ends at the top of page 4, and note that the descriptions of each new status code are provided in section 3.

The desire was for section 2 to stand on its = own to define the statuses and the mapping, and for section 3 to be used to register the statuses in registry.  I believe = it would be cleaner to duplicate the descriptions in this instance. 
As I note, this is a minor issue, but I disagree. Cleaner for _who_? It's certainly not cleaner for the anyone who has to revise this document (and it's not cleaner for you as the editor of this document or the RFC editor since you have to make any change in two places, risking having the document become internally inconsistent). I don't see how it's cleaner for the implementer of the specification either.


We can agree to disagree on this one.  It is = cleaner for the user of the document.  As the editor of the = document, it=E2=80=99s not an issue.  Section 2 provides the = description of the mapping and section 3 is for IANA consideration to = get the missing statuses registered into RDAP JSON Values Registry. =  



Nits:

Near the end of page 3, the document says "In the DNR, the client and server prohibited statuses are separate an RDAP MUST support the same separation." There are several nits to address with this. That MUST is not a good use of 2119. DNR hasn't been expanded (and "the DNR" is not particularly clear).

I suggest you replace that sentence, and the one immediately before it with:

"EPP provides status codes that allow distinguishing the case that an action is prohibited because of server policy from the case that an action is prohibited because of a client request. The ability to make this distinction needs to be preserved in RDAP.=E2=80=9D


This change will be made.  





= --Apple-Mail=_450D0328-09F8-4BEB-9CA1-7EA8294D2C59 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Id: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --Apple-Mail=_450D0328-09F8-4BEB-9CA1-7EA8294D2C59-- --Apple-Mail=_68015AA2-B0FE-4DFA-8E3A-F1B498CAE215-- --Apple-Mail=_016785F7-70FE-427A-81E5-35832C21DEE5 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINszCCBmAw ggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAwMDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50 ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVk aWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2FmTDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F 44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNNRNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0a NomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZBP+gfz+j25FFdmaja/OFI15O2YVddaegFffB AHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6klQrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5 Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gzAgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAG AQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMu Y3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJ LTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9vYIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsG AQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARl MGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9j cHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEF BQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVnMc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGi SNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlUzd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5s Z8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH 5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAqWDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7e DROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gud1wnwTkwggdLMIIGM6ADAgECAhBIc3xqAcyg dUVB04WmvJaFMA0GCSqGSIb3DQEBCwUAMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50 ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsT LENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpT eW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTE2MDIwMjAwMDAwMFoXDTE3MDMwMjIzNTk1OVowbDEiMCAGCSqGSIb3DQEJARYTSkdvdWxk QHZlcmlzaWduLmNvbTEVMBMGA1UEAwwMR291bGQsIEphbWVzMRYwFAYDVQQLDA1FTlRFUlBSSVNF IElUMRcwFQYDVQQKDA5WZXJpU2lnbiwgSW5jLjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAK5CrQLTqk4W/xqh6wUoHdNdJhHEBvxGWk6uC3fHOIWciQNa5bFtU50dRCucnan8eMTrfG3N S+Tz/dPNqXPb2lZij36h42xJEZhI7Q3oTSo5jyVWLlEsHD4kUvT4RRuqkxkCDNCMe5l4N7riVRRk ktrDu846/MvkwXiIpvE5FLvnYXkwAlprUW/jWxq7f9d2J75Gu/lIerD7sWhnSjkfWNLV7mVBl0le OMfBZEViyuzM62zvM4Z8L/IyIzP49qeyTcEOCUutCENWrb/aezPKGngy276TrYLXoJgzfZ4hOdnE 1x/YN7qQmhR0vPLPGwqKijqEKG1xJERfPrvm79mO3F8CAwEAAaOCA4kwggOFMAwGA1UdEwEB/wQC MAAwDgYDVR0PAQH/BAQDAgWgMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMEMB0GA1UdDgQWBBRWhUpo LXEQ8H0RYqrd1avCyQi5+TAeBgNVHREEFzAVgRNqZ291bGRAdmVyaXNpZ24uY29tMB8GA1UdIwQY MBaAFNhIKahfKheS4vqee+9vYIP4uLjcMIIBcQYIKwYBBQUHAQEEggFjMIIBXzAnBggrBgEFBQcw AYYbaHR0cDovL3BraS1vY3NwLnN5bWF1dGguY29tMIIBMgYIKwYBBQUHMAKGggEkbGRhcDovL2Rp cmVjdG9yeS52ZXJpc2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMiUyMFNo YXJlZCUyMEludGVybWVkaWF0ZSUyMENlcnRpZmljYXRlJTIwQXV0aG9yaXR5JTJDT1UlMjAlM0Ql MjBDbGFzcyUyMDIlMjBNYW5hZ2VkJTIwUEtJJTIwSW5kaXZpZHVhbCUyMFN1YnNjcmliZXIlMjBD QSUyQ09VJTIwJTNEJTIwU3ltYW50ZWMlMjBUcnVzdCUyME5ldHdvcmslMkNPJTIwJTNEJTIwU3lt YW50ZWMlMjBDb3Jwb3JhdGlvbiUyQ0MlMjAlM0QlMjBVUz9jQUNlcnRpZmljYXRlO2JpbmFyeTBd BgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vcGtpLWNybC5zeW1hdXRoLmNvbS9jYV8wN2JiN2Q2NDc3 Y2Y0ZjZiZTk2YWYxYjM2Y2FiZDMxNi9MYXRlc3RDUkwuY3JsMGwGA1UdIARlMGMwYQYLYIZIAYb4 RQEHFwIwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUH AgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwQgYJKoZIhvcNAQkPBDUwMzAKBggqhkiG 9w0DBzALBglghkgBZQMEAQIwCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBKjAsBgpghkgBhvhFARAD BB4wHAYSYIZIAYb4RQEQAQICAQGL8cYJFgYyNDc2NjQwOQYKYIZIAYb4RQEQBQQrMCkCAQAWJGFI UjBjSE02THk5d2Eya3RjbUV1YzNsdFlYVjBhQzVqYjIwPTANBgkqhkiG9w0BAQsFAAOCAQEAHapW kLCdJZWxWYsTBnX/6xSiLWdSV3DzAmXtOxsa0R1Lraamp42xravOPyRDqun8Yoinbu1Qjidc3owf ySQbZ0qOkOJJyRCmIMQ91kELa6BrquXuo2JPk/wZEseV0I4Y1dGixc/2QNMPoCo1BDz8lkO+dP5n uEgUgyDo1iiywjjV0bh4Ep4YJgO5qcaAd7zqn8hMjCamMrdNMUQNPIJztGZRC3/Au/aWUTqTAx8x kyX2Y2sfbRxilHSZLkLfZ3aej4mh5oS2jopGv8/mY3lvNl1xZzN23AYOg9fsMKA5tJL1CTDZHCMS hTZASdIvWG+0cSFm446flw4Z3IjneoH6MDGCBE0wggRJAgEBMIHeMIHJMQswCQYDVQQGEwJVUzEd MBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5l dHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlm aWNhdGUgQXV0aG9yaXR5AhBIc3xqAcygdUVB04WmvJaFMAkGBSsOAwIaBQCgggJDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2MTAxMjE0MjcwM1owIwYJKoZIhvcN AQkEMRYEFL+Jr1nFR6vv6Ozz7fGOFkyQFjvyMIHvBgkrBgEEAYI3EAQxgeEwgd4wgckxCzAJBgNV BAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMg VHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0 ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEEhzfGoBzKB1RUHThaa8loUwgfEGCyqGSIb3DQEJEAIL MYHhoIHeMIHJMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQ S0kgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNo YXJlZCBJbnRlcm1lZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AhBIc3xqAcygdUVB04WmvJaF MA0GCSqGSIb3DQEBAQUABIIBABhnsahEle7xaR/xp68E8L4RRVATot5quKTdF7DNNZXDnZnaGoMD rPUEiFGWSVtkOI+rMW1HwRsK7R6izeVBRb7e4faFMt07J+CNw/Oo6iP2y1aQaoI3c1O++BMxAks1 6BpjFbA9nUdXoPnNzc2HQxtpl0CD3WqgrhN/N0PgLRpy6c1RFPGeFtA+jxSPUMBn01EDtRmeaOmY r+xgy2DxNVrz1lYfWAL0QjxTOx88dhFS6zkdZ7ABys+7uv4jJfUcx9KbBXKH0jgu3fLmMSfSHVPc GebaSICRqaA9wQbG1k8glOAOOG7bvXwjt/FJqasm6pX5ocGhMkruVAvDs3c6/W8AAAAAAAA= --Apple-Mail=_016785F7-70FE-427A-81E5-35832C21DEE5--