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 2CD7C1294DD; Tue, 11 Oct 2016 09:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.895 X-Spam-Level: X-Spam-Status: No, score=-4.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no 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 afIhyy2ex12B; Tue, 11 Oct 2016 09:00:50 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C93BC1294BF; Tue, 11 Oct 2016 09:00:49 -0700 (PDT) Received: from unnumerable.local ([47.186.56.40]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u9BG0l39081791 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Tue, 11 Oct 2016 11:00:48 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.56.40] claimed to be unnumerable.local To: "Gould, James" References: <1016282d-9f98-fc86-572d-ca80c10db3a5@nostrum.com> <94AC877C-EE87-4425-8E00-95965F945BA1@verisign.com> From: Robert Sparks Message-ID: Date: Tue, 11 Oct 2016 11:00:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <94AC877C-EE87-4425-8E00-95965F945BA1@verisign.com> Content-Type: multipart/alternative; boundary="------------FEF1AB89F167E473BC5E090C" 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: Tue, 11 Oct 2016 16:00:54 -0000 This is a multi-part message in MIME format. --------------FEF1AB89F167E473BC5E090C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Responses inline - On 10/10/16 10:28 AM, Gould, James wrote: > Robert, > > Thank you for your review and feedback. I provide responses to your > feedback below. > > — > > > JG > > > > > *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 > > 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 >> >> . >> >> 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-values.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 “For DNR that indicates” can be removed from the descriptions. > For example, the "addPeriod = add period; For DRN that indicates if > the object is …” mapping could be "addPeriod = add period; If the > object is …”. 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’s. There is no intent to redefine > the statuses included in the EPP RFC’s 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: addPeriod = 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: 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. > >> >> 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 = 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’s 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. >> 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. >> >> 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.” >> > > This change will be made. > >> > --------------FEF1AB89F167E473BC5E090C Content-Type: multipart/related; boundary="------------8F542C9E43FE781F3D38BA5E" --------------8F542C9E43FE781F3D38BA5E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Responses inline -


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

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

—


JG




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-values.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 “For DNR that indicates” can be removed from the descriptions.  For example, the "addPeriod = add period; For DRN that indicates if the object is …”  mapping could be "addPeriod = add period; If the object is …”.  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’s.  There is no intent to redefine the statuses included in the EPP RFC’s 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:

   addPeriod = 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:

   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.



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 = 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’s 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.

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.



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.”


This change will be made.  




--------------8F542C9E43FE781F3D38BA5E Content-Type: image/png Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vL JtmQhEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjT DnhDEEWC1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBg wDFuRRaXOiUlhX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2Thp UA4w9Pf39/X19fT0UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvCl pSFvipAimGy1wQmrMgV4aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZn ZGSMLYejx4biEautrQ3eUlNTLUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwo MYA5nZ+duXiyur6ju88u5ZL5s+ffmJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMyg UvRoijp7AnuPXdhz9PyeyvPI7khxqtoUyTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIe aOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+ MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUYu3T5MoyxMZEDbJTK81fWlR242NrrcHsd ToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5KhL1kjDMBbMQMDKa6pgaE6enpggp4 r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg8NF7Crc99XNeG/ZQIvkQ3xt1 bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SFSVPIxDKpBVuYQOABMtg3 f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+aw+1xuLQ1Ag9s1p9u C9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhDED8wSxgTYLsq LihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z0S70CNsj wiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4eQOP cELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT 6T5+saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1o PoiPDXtouXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z 3HTYGyVlH5+oalTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScx ZZBtnd0lr31oF9G0l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEY B2jEkLZ91vDtONgwQhgjZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjR rCkTYo5c/fK7yshlTXVkc739+RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffr UI5Aqf7SNz6NuTpInl2xQHlXKJDlCZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z +lCdcbChKoAJY7SBV9PUobMTE3VwQ9MeX/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2cea NI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL 5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/FdrdgkvZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6 dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQLMor+WhVsSozwfVnMdWJ2DpcDZF0M Elj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUpKzYoR7UX1IS7qg+I62+BLALV UGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw1oN3znOkZTsyJg3+pecQ h3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6fG8frR4qH2xaXZzl 12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaUfDqolJR9FHNn 8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/Ly9ASKFfQ soWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg6+nt xeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNc RkE09LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9 So6/0ZoloVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAl DIgT6qCijr9RpfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKF S+dOSHMNqAO+OgSL74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgA Q6EYJGJEKSpORxx/YzZWzlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu3 7FUpnnAKfqWFsEbURI0KfQFs+aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc 4NWWGWZPtG6FUO1Lbm91c9emdypkWT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRs w/SPCBs649ejosWLyePA69W/jD6+aNL0TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOl v+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eBLq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rv jfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHtheMFApjuwY+19N+XlMEIdwrjCCAYzMzPB lmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfrxU8bLnaElNzqRkDukuUTUx8TddxT 0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPxiLiyxRyQADa0QH6rra19b88e fkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/NyN782J1ZGT4FTBcuDjP9 fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI4NQUqa0NNWkqPMIb pAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2eOTHpM8vdh3+ ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzYu3r16ifl 5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfnFWSn MYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqc NpaYTgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtk TMATCfNyc/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55Mkdw IOGi/IgB4GRgxJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav 8CIKCCnSNuPHqTEu2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4 pS5wGNCFnE4CHH5wzLfujS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VX XyVZ298iRFFR0dKlS+k0b1966SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQF U6euf/ppGma6SLVz586TJ0/Sj/DO24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABj QEVFxfPPP09+jxgMMKCKFpCBIoNf0fjNYPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7 oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqqFVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFB oYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxItm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBX ZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQexTCSw616MzcyJwIZr8UqYoQHJZqQ0 0KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwqbMYsASa82UljgCjbzIloGKrp R4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNauLDPXNBQ2Y5Zsb2aaETTQ jTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McYO3syWGgnRNkB29eh bZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCxJ+ONl8ojtTAJ IWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1ol2MUFaQ GrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8JGPDD ecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --------------8F542C9E43FE781F3D38BA5E-- --------------FEF1AB89F167E473BC5E090C--