I also agree that exact match is best. At the time we issue the create command, we have already stored what we expect to be charged for that transaction and used it in other calculations.
Maybe instead of picking one, we can add an attribute to the <fee:fee> element like <fee:fee match="exact"> where the valid values are "exact", or "inexact" or better terminology TBD. With exact being the default if it isn't specified. And of course, we would need a corresponding attribute for the <fee:credit> element as well. This allows flexibility and make's the inexact match an explicit choice made by the registrar. Thanks, -Pat On Thu, Mar 30, 2017 at 10:40 AM Feher, Kal <kalman.fe...@neustar.biz> wrote: I personally think an exact match is best. The represented fee is that of the server, not what the Registrar will charge the registrant (which could be above or below the registry price). If we want to ensure that the Registrar correctly understands the price at the time of transaction, then exact match is the only mechanism to be sure of this. With our own extension for premium names we had exactly this discussion internally and ultimately opted for either an exact match or a simple 'non-standard price' acknowledgement. The reasoning being that if a Registrar specified a price, they wanted to ensure correctness and if a Registrar specified an acknowledgment they were satisfied using offline/out of band sources for price. Since discounting and mark up pricing are normal practices for Registrars, we can't presume that an incorrect value in either direction (above or below) is acceptable. My 2 cents (in AUD so therefore 1.6 cents) I originally posted this reply using a non-subscribed address, so apologies to those who've received it twice. On 30/3/17, 07:50, "regext on behalf of Jody Kolker" <regext-boun...@ietf.org on behalf of jkol...@godaddy.com> wrote: >Alex wrote: > >>> >No. Each fee involved would need to be equal or over the fee required by >the server. >>> > >Agreed. > >Thanks, >Jody Kolker >319-294-3933 <(319)%20294-3933> (office) >319-329-9805 <(319)%20329-9805> (mobile) Please contact my direct supervisor Charles >Beadnall (cbeadn...@godaddy.com) with any feedback. > >This email message and any attachments hereto is intended for use only by >the addressee(s) named herein and may contain confidential information. >If you have received this email in error, please immediately notify the >sender and permanently delete the original and any copy of this message >and its attachments. > > > >-----Original Message----- >From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Alexander >Mayrhofer >Sent: Wednesday, March 29, 2017 4:36 PM >To: Thomas Corte <thomas.co...@knipp.de>; regext@ietf.org >Cc: supp...@tango-rs.com >Subject: Re: [regext] draft-ietf-regext-epp-fees > > > >Thomas Corte wrote: >> I just realized that the agreement seems to be that it is OK to >> specify a larger fee than actually charged by the server. > >Yes. And i think it's good. > >> I don't think this is a good idea, I'd prefer requiring a perfect >> match of all fees. Sure, allowing the specification of larger fees >> still guards the registrar from losing money, but it will also >> potentially lead to the registrar unintendedly overcharging a customer >> if e.g. fees are statically configured in a registrar's system, and a >> price change notification is missed. > >We can never prevent registrars from "overcharging" a customer, and i do >consider it out of scope for the IETF. What i don't consider out of scope >of the IETF, however, is the robustness principle of "be conservative >what you send, be liberal in what you accept". Especially in situations >where there's a rush for names, a failed transaction just because someone >"overbid" the registry could create problems. > >Further, requiring a "perfect match" would prevent models like dutch >auctions, where prices slowly decrease over time. A check could never >reflect the actual, current price, so "overbidding" is required in such >situations. More hypothetically, but, possible. > >> It also raises the question what to do when multiple fees are involved. >> If the server e.g. charges 50 for creating an initial application >> (immediate) and 50 later upon a domain's allocation (delayed), should >> the server accept it if the registrar specifies 60 (immediate) and 40 >> (delayed), i.e. if the total sum of the fees in the create request is >> sufficient, but the individual amounts don't match? > >No. Each fee involved would need to be equal or over the fee required by >the server. > >> At the very least, I'd leave it up to a server's policy to accept fees >> which are higher than the actually assessed fees. > >I do suggest that the text says something like the following only (only >make clear that fees must be sufficient, but don't specify what happens >if they are above the required value): > >"A server MUST reject a transform command if client supplied fee values >for the fees involved in the transaction are lower than the server >requires" > >(in better english ;) > >Alex > > >_______________________________________________ >regext mailing list >regext@ietf.org >https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_ >listinfo_regext&d=DwIFAw&c=MOptNlVtIETeDALC_lULrw&r=XJpLGAYHqo0Qxw2Kvg7mfn >ZOGGHKaGjevV2N8lDb4mU&m=6ZnnmrNdgvd01-Bs3v8GcJ_rWCJqhjTwRL2it_VMQCU&s=jGL9 >-go8JMg-qLtcWgfWYImA0Gqy2N10SGPy8eZiRyo&e= > >_______________________________________________ >regext mailing list >regext@ietf.org >https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_ >listinfo_regext&d=DwIFAw&c=MOptNlVtIETeDALC_lULrw&r=XJpLGAYHqo0Qxw2Kvg7mfn >ZOGGHKaGjevV2N8lDb4mU&m=6ZnnmrNdgvd01-Bs3v8GcJ_rWCJqhjTwRL2it_VMQCU&s=jGL9 >-go8JMg-qLtcWgfWYImA0Gqy2N10SGPy8eZiRyo&e= _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- -Pat Moroney Sr. Software Engineer Name.com http://www.youtube.com/watch?v=V1GKGXXF12c 720-663-0025
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
