Return-Path: X-Original-To: eppext@ietfa.amsl.com Delivered-To: eppext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F9F1AD35D for ; Mon, 7 Dec 2015 13:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 iy9UJwOV6n6o for ; Mon, 7 Dec 2015 13:53:55 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 35E191AD35B for ; Mon, 7 Dec 2015 13:53:55 -0800 (PST) Received: by qkdp187 with SMTP id p187so1455895qkd.1 for ; Mon, 07 Dec 2015 13:53:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=name-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=JxPnzaRRFdXF9UDSAjbGR0/bqa1c6KohMsJYQdYYtwk=; b=TmULQ+r/Asn49s36CDSJH4rprbmCWIBKPKEvIT/bu2hnpQoOAK+5vt1KwKYkV1BAnI jF6chZGHUSMq7YXdDWC0VWafQGRWuw2qxUCiCT8RtUV/dj3FRWQjUmV9TEucqkW2I3D4 XVm9RUn2gDFV9+6K0enyksrADUqU2EHlJtpD57jpdAdMpX9qkLaPkPNC4rWh2ByPoaOZ qh959w5+LUuGnBuXQqeLfhDEk/pLFIkbaVLv5q2ttllvxa64eE+SPYE/xN4wsExsmDqd rbGug3hmRHJG5GRvy3+6q9zejyAFTmsOSgA8CtBRJSj51Jgzs74+hUpN310DlSid97zY GtkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=JxPnzaRRFdXF9UDSAjbGR0/bqa1c6KohMsJYQdYYtwk=; b=dRwrwjXxKm3/35181IZ0vqVxOcokionINKuD6Zb9kmi8jE5momCC/mOGQDJqp6L9p+ XDVxIhwtswth4ddANcpJoKq/CxByGLYgfMTeqSSpJNKocFSoN6g2v6OxOHME6zKzrvke kI2GcMsDfzAy3xCbGg/ANeOqc6fob28mec5HdcOqVN7fKnkXsrIyC36gatbDr4e4eNwb BpUwGUKtYFHA+XZYZa2lpe8+UCoPErbDlRhHHg+9/sq2cus7/SaE1VeupV+5kizr60xI 9KAU0dR4UHkPPbyDSAiy2P8n4hbdI4u15vNxuc5G6RAQpUVrMC3GcHuNuQnCw0B8Sr6a cgBw== X-Gm-Message-State: ALoCoQk+GgHWLuFXYlaPci0ULu4TFjVDz9HWGi97AKA4IDhvVq+ZwXRB7agt+jdh1DCN/RFROp+p1Juya0KsSK5mgIag5189qMtPjDUcbpqXxZ0bLbHacDk= X-Received: by 10.13.200.134 with SMTP id k128mr48886ywd.62.1449525234069; Mon, 07 Dec 2015 13:53:54 -0800 (PST) MIME-Version: 1.0 References: <3e66897b2c554706980f6973c953c43e@ka-mbx02.SIDN.local> In-Reply-To: <3e66897b2c554706980f6973c953c43e@ka-mbx02.SIDN.local> From: Pat Moroney Date: Mon, 07 Dec 2015 21:53:44 +0000 Message-ID: To: Marc Groeneweg , "eppext@ietf.org" Content-Type: multipart/related; boundary=001a114d3a1aabe143052655e4a4 Archived-At: Subject: Re: [eppext] New Version Notification for draft-brown-epp-fees-06.txt X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 21:54:02 -0000 --001a114d3a1aabe143052655e4a4 Content-Type: multipart/alternative; boundary=001a114d3a1aabe141052655e4a3 --001a114d3a1aabe141052655e4a3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable James, Marc, Currently for our check commands sent for searches, this is what we request for fees: create command for 1 year in the current phase renew command for 1 year in the GA phase create command for 1 year in the GA phase if the current phase is sunrise or landrush. create command for 1 year in the landrush phase if the current phase is sunrise. We never request a fee for a domain that is not included in the check command. We do this because we calculate prices for each of these in our search results. Removing the ability to get this data in a check response will require us to perform multiple commands for searches, which will always be slower then performing a single command that gets the same information. The check command is the only command that operates on non-existent objects. Combining that with the fact that the check command can return the availability of multiple domains in a single command makes it better suited to return data that is necessary for search results. Modifying the info command to respond without an error when an object does not exist upsets the idealist in me more then returning more information in the check command. Also the idea of sending additional multiple millions of info commands per day upsets the pragmatic in me. Performing a fee check on a domain that does not exist happens a couple of orders of magnitude more times then performing a fee check on a domain that exists. That is why removing the extension from the info command wasn't a big deal. In our case, performing an availability check without performing these fee checks never happens, so removing the extension from the check command would be a big deal. Thanks, -Pat On Mon, Dec 7, 2015 at 2:13 AM Marc Groeneweg wrote: > Pat, James, etal., > > > > I have to agree with James on this one. Shouldn=E2=80=99t we create a sim= ple check > for checking availability of a domain name (as supposed) extended with th= e > current fee (given the period the registry/domain phase is in). And exten= d > the info command with more complex fee information. The perceived respons= e > time for a check command is very, very small =E2=80=98cause its such a sm= all, and > powerful command. > > > > Regards, > > Marc > > > > *From:* EppExt [mailto:eppext-bounces@ietf.org] *On Behalf Of *Gould, > James > *Sent:* vrijdag 4 december 2015 23:55 > *To:* Pat Moroney > *Cc:* Roger D Carney; eppext@ietf.org > > > *Subject:* Re: [eppext] New Version Notification for > draft-brown-epp-fees-06.txt > > > > Pat, > > > > You don=E2=80=99t have an issue with applying a common list of commands a= nd > periods across the list of objects in the check command? Was your plan > with draft-brown-epp-fees-06 to include multiple elements wi= th > the same value, but with different and > values to obtain a fee table or a set of fees for a domain? > My main concern is overloading the use of the check command for something > that looks and feels like a query (info) interface. It just feels odd to > leverage the extended check command to get fee information for existing > domain names. My idealist side is really starting to get concerned with > the mixing of the availability check with a fee query service. It would = be > best to keep the check simple and provide for a limited set of fee > information (one command and period along with the domain availability) a= s > a true extension of the availability check to quickly provide the > availability and create fee for each available object or provide a fee > table for each available object (billable commands and fees by period > ranges). A more powerful query interface could be provided to support mo= re > elaborate searches, which is best with the info command and response that > was removed in draft-brown-epp-fees-05. I realize that it is preferred f= or > everything to be provided in a single command and response, but the speed > and simplicity of the check is really being put at risk. > > > > =E2=80=94 > > > > JG > > > > > > *James Gould *Distinguished Engineer > jgould@Verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > VerisignInc.com > > > > On Dec 4, 2015, at 3:20 PM, Pat Moroney wrote: > > > > James, > > > > The pragmatist version is of course favorable to me, but the ability to > ask for fees relating to multiple commands and/or phases is incredibly > useful. Without that ability we would still have to send multiple command= s > since we also request the fees for renewals as well as registrations when > we perform a check. This allows us to provide pricing for purchasing and > give our customers an idea of the renewal pricing that they will see next > year. Multiple phases is also useful that way we can calculate the price > for pre-registrations and pre-landrush while in the sunrise phase with on= ly > one command. > > > > So removing the objects and having a and one or > more and optionally many elements that apply t= o > the list of objects referenced in the check command. The response format > can stay the same. Would that be your pragmatic suggestion? > > > > Thanks, > > -Pat > > > > On Fri, Dec 4, 2015 at 12:11 PM Gould, James wrote: > > Pat & Roger, > > > > Let me clarify from two different perspectives: > > > > Idealist: > > The fee information really doesn=E2=80=99t follow the semantics of a chec= k, but > follows the semantics of an info. The check command is setup as a > container of boolean checks of the existence or availability of something > (domain, claim, contact identifier, etc.). The info command provides the > query information for general information. The fee extension is not aski= ng > for the existence or availability of something, but is asking for fee > information given query inputs. The query inputs may be invalid, so one = of > my questions is what should the server return for each of the invalid > inputs (objID, objURI, objID, element, currency, command, and period)? T= he > check command should be simple and fast, where extending it with addition= al > query or separate check information runs the risk of making it complex an= d > slow. > > > > Pragmatist: > > If a fee is needed for every domain check, then we need a mechanism to > support fee information as an extension to check. To keep it a true > extension, the only elements needed in the element should be > , , and that apply across all of > the check identifiers () included under the check command > (). This would result in a check response including a > element that matches what is currently defined > in draft-brown-epp-fees-06, except the elements would always > correspond to a response identifier (). If there is invalid > input provided with , , or , the > check command should fail with a specified EPP error code (my guess is > 2306, since invalid input would be based on server policy). > > > > I=E2=80=99m assuming that the pragmatist is favorable over the idealist, = but the > idealist in me has a real concern of overloading the check command / > response as a pattern to combine commands / responses. > > > > =E2=80=94 > > > > JG > > > > > > *James Gould *Distinguished Engineer > jgould@Verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > VerisignInc.com > > > > On Dec 4, 2015, at 11:29 AM, Pat Moroney wrote: > > > > Hi all, > > > > I have to agree with Roger. The vast majority of check commands that we > send are triggered by a customer searching on our website. To create the > search results we need both the availability and the fee information in > order to calculate the pricing. We can currently get that with one check > command, but if it is split up our command volume will almost double. > > > > Thanks, > > -Pat > > > > On Fri, Dec 4, 2015 at 9:20 AM Roger D Carney wrote= : > > Good Morning, > > > > Interesting idea Jim. Though not completely disagreeing with your premise > that the check and fee have different purposes, let me play devil=E2=80= =99s > advocate here with some knowledge on the separate claims check in mind as > well. Different individual purposes maybe but when looking at the varied > data flow scenarios (how is this data used and presented to the end > customer), I believe most clients would see the purposes aligned well. > > > > I have heard from many people with the same question about claims: =E2=80= =9CWhy do > we have to make two calls to see if a domain has a claim associated to it= , > can=E2=80=99t they just tell us in the check?=E2=80=9D > > > > I am guessing the same question will come up if it is a separate call for > fee information as well. People may make the argument that the additional > claims check is only needed for a specific period of time (except for tho= se > doing indefinite claims). I think everyone would agree this same argument > does not apply for fees and as we see more and more varied wholesale mode= ls > I think an integrated call is more natural and becomes more necessary. > > > > Again, as these concepts align well from a flow perspective and as the > probability of expanding wholesaling models increases, I believe most > clients would prefer (demand) one call over multiple calls. > > > > > > Thanks > > Roger > > > > > > *From:* EppExt [mailto:eppext-bounces@ietf.org] *On Behalf Of *Gould, > James > *Sent:* Friday, December 04, 2015 7:37 AM > *To:* Gavin Brown > *Cc:* eppext@ietf.org > *Subject:* Re: [eppext] New Version Notification for > draft-brown-epp-fees-06.txt > > > > Gavin, > > > > In reviewing draft-brown-epp-fees-06, I have the following feedback: > > > > 1. The fee check extension is really not a good fit for extension of > the available check. They have different purposes and there is really= no > relationship between the two, where the availability check can include= a > completely different set of domain names from getting the fee extensio= n. > My recommendation is to separate the two and define the fee check as a= new > verb similar to the claims check in draft-ietf-eppext-launchphase. An= other > option is truly extend the object identifiers (e.g. domain:names) in t= he > check command with a set of fee attributes to get the fee information = for. > Have the extension only specify the command and the optional currency = and > fee that applies to all of the names in the availability check command= . > The response would include the same list of object identifiers in the > extension, but it would be a one-to-one relationship. In this way the= re is > no need for the =E2=80=9CobjURI=E2=80=9D attribute, the el= ement, and > =E2=80=9Celement=E2=80=9D attribute in the check command, = since the object and > identifying element is already defined by the availability check objec= t > that is being extended. > 2. What should be returned when the client passes invalid data in the > check command for the the =E2=80=9CobjURI=E2=80=9D attribute (e.g. =E2= =80=9Curn:made:up:uri=E2=80=9D), the > element (e.g. invalid domain name), the =E2=80=9Celement= =E2=80=9D attribute of > (e.g. =E2=80=9Cmadeup=E2=80=9D), the elemen= t (e.g. =E2=80=9CMUP=E2=80=9D), and > the element (e.g. =E2=80=9C99" when max is =E2=80=9C10=E2= =80=9D)? An invalid > is covered by not returning the fee information, but it= =E2=80=99s > unclear whether the server should return an error or not return the fe= e > information for other invalid data. To follow the semantics of a chec= k > command and response, my recommendation is to add an =E2=80=9Cavail=E2= =80=9D attribute to > either or to explicitly indicate that the fee > information is available along with an optional to indica= te > the reason that the fee information is not available. The reason the = fee > information is not available for a particular object could be due to t= he > passing of invalid input in the check command element. I= f you > went with a single set of fee elements in the check command that is ap= plied > to all of the object identifiers in the availability check, then an in= valid > fee element could result in a failure of the check command itself inst= ead > of being an error (e.g. not available) on a per domain basis. > 3. Since the check response supports returning a =E2=80=9C0.00=E2=80= =9D value to > indicate no fee, doesn=E2=80=99t make sense to do the same with all tr= ansform > command responses? > > > > > > =E2=80=94 > > > > JG > > > > > > *James Gould *Distinguished Engineer > jgould@Verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > VerisignInc.com > > > > On Nov 4, 2015, at 5:58 PM, Gavin Brown > wrote: > > > > Changes from 05 to 06: > > 1. The specification is now object-agnostic, but works with RFC5731 > [RFC5731] domains by default. > > 2. Renamed the element to . Added the > "objURI" attribute. > > 3. Removed the default value for the "refundable" attribute of > elements, and added text about how clients should > handle such cases. Added similar text to the documentation of > the "grace-period" attribute. > > 4. Removed references to the defunct command syntax. > > 5. "MUST" requirements regarding documentation have been changed to > "must". > > 6. Created separate "Correlation between Refundability and Grace > Periods" section describing how the "refundable" and "grace- > period" attributes work together. > > Feedback welcome as always! > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-brown-epp-fees-06.txt > Date: Wed, 04 Nov 2015 14:52:30 -0800 > From: internet-drafts@ietf.org > To: Gavin Brown , Jothan Frakes > > > > A new version of I-D, draft-brown-epp-fees-06.txt > has been successfully submitted by Gavin Brown and posted to the > IETF repository. > > Name: draft-brown-epp-fees > Revision: 06 > Title: Registry Fee Extension for the Extensible Provisioning Protocol > (EPP) > Document date: 2015-11-04 > Group: Individual Submission > Pages: 36 > URL: > https://www.ietf.org/internet-drafts/draft-brown-epp-fees-06.txt > Status: https://datatracker.ietf.org/doc/draft-brown-epp-fees/ > Htmlized: https://tools.ietf.org/html/draft-brown-epp-fees-06 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-brown-epp-fees-= 06 > > Abstract: > This document describes an Extensible Provisioning Protocol (EPP) > extension mapping for registry fees. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > -- > Gavin Brown > Chief Technology Officer > CentralNic Group plc (LSE:CNIC) > Innovative, Reliable and Flexible Registry Services > for ccTLD, gTLD and private domain name registries > https://www.centralnic.com/ > > CentralNic Group plc is a company registered in England and Wales with > company number 8576358. Registered Offices: 35-39 Moorgate, London, > EC2R 6AR. > > > > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext > > > > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext > > -- > > -Pat Moroney > > Sr. Software Engineer > > Name.com > > http://www.youtube.com/watch?v=3DV1GKGXXF12c > > 720-663-0025 > > _____________________________________________= __ > > > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext > > -- > > -Pat Moroney > > Sr. Software Engineer > > Name.com > > http://www.youtube.com/watch?v=3DV1GKGXXF12c > > 720-663-0025 > > > > > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext > --=20 -Pat Moroney Sr. Software Engineer Name.com http://www.youtube.com/watch?v=3DV1GKGXXF12c 720-663-0025 --001a114d3a1aabe141052655e4a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
James, Marc,

Currently for our check co= mmands sent for searches, this is what we request for fees:
creat= e command for 1 year in the current phase
renew command for=C2=A01 year in the=C2=A0GA phase<= /span>
create command for= =C2=A01 year in the=C2=A0GA phase if the current phase is sunrise = or landrush.
create = command for=C2=A01 year in the=C2=A0landrush phase if the current phase is sunrise.=

We never request a fee for a domain that = is not included in the check command.

We = do this because we calculate prices for each of these in our search results= . Removing the ability to get this data in a check response will require us= to perform multiple commands for searches, which will always be slower the= n performing a single command that gets the same information.=C2=A0<= /div>

The check command is the only command that operate= s on non-existent objects.=C2=A0Combi= ning that with the fact that the check command can return the availability = of multiple domains in a single command makes it better suited to return da= ta that is=C2=A0necessary=C2=A0for search results.
Modifying the info command to respond without an e= rror when an object does not exist upsets the idealist in me more then retu= rning more information in the check command. Also the idea of sending=C2=A0= additional multiple=C2=A0millions of= =C2=A0info commands per day upsets the pragmatic in me.=C2=A0
<= div>
Performing a fee check on a domain that does not exist h= appens a couple of orders of magnitude more times then performing a fee che= ck on a domain that exists. That is why removing the extension from the inf= o command wasn't a big deal.
In our case, performing an avail= ability check without performing these fee checks never happens, so removin= g the extension from the check command would be a big deal.

<= /div>
Thanks,
-Pat

=
On Mon, Dec 7, 2015 at 2:13 AM Marc Groeneweg <Marc.Groeneweg@sidn.nl> wrote:

Pat, James, etal.,=

=C2=A0

I have to = agree with James on this one. Shouldn=E2=80=99t we create a simple check fo= r checking availability of a domain name (as supposed) extended with the current fee (given the period the registry/domain phase is in). And ex= tend the info command with more complex fee information. The perceived resp= onse time for a check command is very, very small =E2=80=98cause its such a= small, and powerful command.

=C2= =A0

Regards,

Marc

=C2= =A0

From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Gould, James
Sent: vrijdag 4 december 2015 23:55
To: Pat Moroney
Cc: Roger D Carney; eppext@ietf.org

<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"= ;,"sans-serif"">
Subject: Re: [eppext] New Version Notification for draft-brown-epp-f= ees-06.txt

=C2=A0

Pat,

=C2=A0

You don=E2=80=99t have an issue with applying a comm= on list of commands and periods across the list of objects in the check com= mand?=C2=A0 Was your plan with=C2=A0draft-brown-epp-fees-06 to include mult= iple <fee:object> elements with the same <fee:objID> value, but with different <fee:command> and <fee:period> value= s to obtain a fee table or a set of fees for a domain?=C2=A0 My main concer= n is overloading the use of the check command for something that looks and = feels like a query (info) interface.=C2=A0 It just feels odd to leverage the extended check command to get fee information for exis= ting domain names.=C2=A0 My idealist side is really starting to get concern= ed with the mixing of the availability check with a fee query service.=C2= =A0 It would be best to keep the check simple and provide for a limited set of fee information (one command and period a= long with the domain availability) as a true extension of the availability = check to quickly provide the availability and create fee for each available= object or provide a fee table for each available object (billable commands and fees by period ranges).=C2=A0= A more powerful query interface could be provided to support more elaborat= e searches, which is best with the info command and response that was remov= ed in draft-brown-epp-fees-05.=C2=A0 I realize that it is preferred for everything to be provided in a single command and= response, but the speed and simplicity of the check is really being put at= risk. =C2=A0

=C2=A0

=E2=80=94

<= u>=C2=A0

JG


=

James Gould
Distinguished Engineer
jgould@Verisign.co= m

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

VerisignInc.com

=C2=A0

On Dec 4, 2015, at 3:20 PM, Pat Moroney <pmoroney@name.com> w= rote:

=C2=A0

James,

=C2=A0

The pragmatist version is of course favorable to me,= but the ability to ask for fees relating to multiple commands and/or phase= s is incredibly useful. Without that ability we would still have to send mu= ltiple commands since we also request the fees for renewals as well as registrations when we perform a check. Th= is allows us to provide pricing for purchasing and give our customers an id= ea of the renewal pricing that they will see next year. Multiple phases is = also useful that way we can calculate the price for pre-registrations and pre-landrush while in the sunrise phas= e with only one command.

=C2=A0

So removing the <fee:objID> objects and having= a <fee:period> and one or more <fee:command> and optionally ma= ny <fee:period> elements that apply to the list of objects referenced= in the check command. The response format can stay the same. Would that be your pragmatic suggestion?

=C2=A0

Thanks,

-Pat

=C2=A0

On Fri, Dec 4, 2015 at 12:11 PM Gould, James <JGould@verisign.com> wrote:

Pat & Roger,

=C2=A0

Let me clarify from two different perspectives:

=C2=A0

Idealist:=C2=A0

The fee information really doesn=E2=80=99t follow th= e semantics of a check, but follows the semantics of an info.=C2=A0 The che= ck command is setup as a container of boolean checks of the existence or av= ailability of something (domain, claim, contact identifier, etc.).=C2=A0 The info command provides the query information f= or general information.=C2=A0 The fee extension is not asking for the exist= ence or availability of something, but is asking for fee information given = query inputs.=C2=A0 The query inputs may be invalid, so one of my questions is what should the server return for each of the in= valid inputs (objID, objURI, objID, element, currency, command, and period)= ?=C2=A0 The check command should be simple and fast, where extending it wit= h additional query or separate check information runs the risk of making it complex and slow.=C2=A0

=C2=A0

Pragmatist:

If a fee is needed for every domain check, then we n= eed a mechanism to support fee information as an extension to check.=C2=A0 = To keep it a true extension, the only elements needed in the <fee:check&= gt; element should be <fee:currency>, <fee:command>, and <fee:period> that apply across all of the check identifiers (<= ;domain:name>) included under the check command (<domain:check>).= =C2=A0 This would result in a check response including a <fee:chkData>= ; element that matches what is currently defined in=C2=A0draft-brown-epp-fe= es-06, except the <fee:objID> elements would always correspond to a respons= e identifier (<domain:name>).=C2=A0 If there is invalid input provide= d with <fee:currency>, <fee:command>, or <fee:period>, th= e check command should fail with a specified EPP error code (my guess is 2306, since invalid input would be based on server policy). =C2=A0

=C2=A0

I=E2=80=99m assuming that the pragmatist is favorabl= e over the idealist, but the idealist in me has a real concern of overloadi= ng the check command / response as a pattern to combine commands / response= s. =C2=A0

On Dec 4, 2015, at 11:29 AM, Pat Moroney <pmoroney@name.com> w= rote:

=C2=A0

Hi all,

=C2=A0

I have to agree with Roger. The vast majority of che= ck commands that we send are triggered by a customer searching on our websi= te. To create the search results we need both the availability and the fee = information in order to calculate the pricing. We can currently get that with one check command, but if it i= s split up our command volume will almost double.

=C2=A0

Thanks,

-Pat

=C2=A0

=
=

On Fri, Dec 4, 2015 at 9:20 AM Roger D Carney <rcarney@godaddy.com<= /a>> wrote:

=

Good Mo= rning,

=C2=A0<= /span>

Interes= ting idea Jim. Though not completely disagreeing with your premise that the= check and fee have different purposes, let me play devil=E2=80=99s advocate here with some knowledge on the separate claims check in mind as = well. Different individual purposes maybe but when looking at the varied da= ta flow scenarios (how is this data used and presented to the end customer)= , I believe most clients would see the purposes aligned well.

=C2=A0<= /span>

I have = heard from many people with the same question about claims: =E2=80=9CWhy do= we have to make two calls to see if a domain has a claim associated to it, can=E2=80=99t they just tell us in the check?=E2=80=9D

=C2=A0<= /span>

I am gu= essing the same question will come up if it is a separate call for fee info= rmation as well. People may make the argument that the additional claims check is only needed for a specific period of time (exce= pt for those doing indefinite claims). I think everyone would agree this sa= me argument does not apply for fees and as we see more and more varied whol= esale models I think an integrated call is more natural and becomes more necessary.

=C2=A0<= /span>

Again, = as these concepts align well from a flow perspective and as the probability= of expanding wholesaling models increases, I believe most clients would prefer (demand) one call over multiple calls.

=C2=A0<= /span>

=C2=A0<= /span>

Thanks<= /span>

Roger

=C2=A0<= /span>

=C2=A0<= /span>

From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Gould, James
Sent: Friday, December 04, 2015 7:37 AM
To: Gavin Brown
Cc: eppext@ietf= .org
Subject: Re: [eppext] New Version Notification for draft-brown-epp-f= ees-06.txt

=

=C2=A0

Gavin,

=C2=A0

In reviewing draft-brown-epp-fe= es-06, I have the following feedback:

=C2=A0

  1. The fee check extension is really not a good fit for e= xtension of the available check.=C2=A0 They have different purposes and the= re is really no relationship between the two, where the availability check = can include a completely different set of domain names from getting the fee extension.=C2=A0 My recommendation is= to separate the two and define the fee check as a new verb similar to the = claims check in draft-ietf-eppext-launchphase.=C2=A0 Another option is trul= y extend the object identifiers (e.g. domain:names) in the check command with a set of fee attributes to get the fee informati= on for.=C2=A0 Have the extension only specify the command and the optional = currency and fee that applies to all of the names in the availability check= command.=C2=A0 The response would include the same list of object identifiers in the extension, but it would be a on= e-to-one relationship.=C2=A0 In this way there is no need for the =E2=80=9C= objURI=E2=80=9D attribute, the <fee:objID> element, and <fee:objID= > =E2=80=9Celement=E2=80=9D attribute in the check command, since the ob= ject and identifying element is already defined by the availability check object th= at is being extended. =C2=A0=C2=A0
  2. What should be returned when the client passes invalid= data in the check command for the the =E2=80=9CobjURI=E2=80=9D attribute (= e.g. =E2=80=9Curn:made:up:uri=E2=80=9D), the <fee:objID> element (e.g= . invalid domain name), the =E2=80=9Celement=E2=80=9D attribute of <fee:= objID> (e.g. =E2=80=9Cmadeup=E2=80=9D), the <fee:currency> element (e.g. =E2=80=9CMUP=E2=80=9D), and the <= ;fee:period> element (e.g. =E2=80=9C99" when max is =E2=80=9C10=E2= =80=9D)?=C2=A0 An invalid <fee:command> is covered by not returning t= he fee information, but it=E2=80=99s unclear whether the server should retu= rn an error or not return the fee information for other invalid data.=C2=A0 To follow the semantics of a che= ck command and response, my recommendation is to add an =E2=80=9Cavail=E2= =80=9D attribute to either <fee:cd> or <fee:objID> to explicitl= y indicate that the fee information is available along with an optional <fee:reason> to indicate the reason that the fee information is not = available.=C2=A0 The reason the fee information is not available for a part= icular object could be due to the passing of invalid input in the check com= mand <fee:object> element.=C2=A0 If you went with a single set of fee elements in the check command that is applied to all o= f the object identifiers in the availability check, then an invalid fee ele= ment could result in a failure of the check command itself instead of being= an error (e.g. not available) on a per domain basis. =C2=A0 =C2=A0=C2=A0
  3. Since the check response supports returning a =E2=80= =9C0.00=E2=80=9D value to indicate no fee, doesn=E2=80=99t make sense to do= the same with all transform command responses? =C2=A0 =C2=A0=C2=A0<= u>

=C2=A0

=
<= div>

=C2=A0

=E2=80=94

=C2=A0=

JG




James Gould
Distinguished Engine= er
jgould@Verisign.c= om

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

VerisignInc.com

=C2=A0

On Nov 4, 2015, at 5:58 PM, Gav= in Brown <gavin.brown@centralnic.com> wrote:

=C2=A0

Changes from 05 to 06:

=C2=A0=C2=A01.=C2=A0 The specification is now object-agnostic, but works wi= th RFC5731
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[RFC5731] domains by default.

=C2=A0=C2=A02.=C2=A0 Renamed the <fee:domain> element to <fee:obje= ct>.=C2=A0 Added the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"objURI" attribute.

=C2=A0=C2=A03.=C2=A0 Removed the default value for the "refundable&quo= t; attribute of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<fee:fee> elements, and added tex= t about how clients should
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0handle such cases.=C2=A0 Added similar = text to the documentation of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the "grace-period" attribute.=

=C2=A0=C2=A04.=C2=A0 Removed references to the defunct <info> command= syntax.

=C2=A0=C2=A05. =C2=A0"MUST" requirements regarding documentation = have been changed to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"must".

=C2=A0=C2=A06.=C2=A0 Created separate "Correlation between Refundabili= ty and Grace
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Periods" section describing how th= e "refundable" and "grace-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0period" attributes work together.<= br>
Feedback welcome as always!

-------- Forwarded Message --------
Subject: New Version Notification for draft-brown-epp-fees-06.txt
Date: Wed, 04 Nov 2015 14:52:30 -0800
From: interne= t-drafts@ietf.org
To: Gavin Brown <gavin.brown@centralnic.com>, Jothan Frakes
<jothan@jothan.co= m>


A new version of I-D, draft-brown-epp-fees-06.txt
has been successfully submitted by Gavin Brown and posted to the
IETF repository.

Name: draft-brown-epp-fees
Revision: 06
Title: Registry Fee Extension for the Extensible Provisioning Protocol
(EPP)
Document date: 2015-11-04
Group: Individual Submission
Pages: 36
URL:
https://www.ietf.org/internet-drafts/draft-brown-epp-fe= es-06.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://d= atatracker.ietf.org/doc/draft-brown-epp-fees/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org= /html/draft-brown-epp-fees-06
Diff: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-brown-epp-fees-06

Abstract:
=C2=A0=C2=A0This document describes an Extensible Provisioning Protocol (EP= P)
=C2=A0=C2=A0extension mapping for registry fees.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centr= alnic.com/

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.



_______________________________________________
EppExt mailing list
EppExt@ietf.org = https://www.ietf.org/mailman/listinfo/eppext

=C2=A0

_______________________________________________
EppExt mailing list
EppExt@ietf.org = https://www.ietf.org/mailman/listinfo/eppext

=

--

-Pat M= oroney

Sr. So= ftware Engineer

Name.com<= /p>

720-66= 3-0025

=
=

<image001.png><image001.png>____________= ___________________________________

--

-Pat M= oroney

Sr. So= ftware Engineer

720-66= 3-0025

<BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png>= <BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png>

_______________________________________________
EppExt mailing list
EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext
--
-Pat Moroney
Sr. Software Engineer
Name.com
720-663-0025
--001a114d3a1aabe141052655e4a3-- --001a114d3a1aabe143052655e4a4 Content-Type: image/png; name="image001.png" Content-Disposition: inline; filename="image001.png" Content-Transfer-Encoding: base64 Content-ID: <1517e18806d4cff311> X-Attachment-Id: 1517e18806d4cff311 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= --001a114d3a1aabe143052655e4a4 Content-Type: image/png; name="image001.png" Content-Disposition: inline; filename="image001.png" Content-Transfer-Encoding: base64 Content-ID: <> X-Attachment-Id: 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= --001a114d3a1aabe143052655e4a4--