Re: Registry Fee Extension for the Extensible Provisioning Protocol

I agree with James' suggestion that the extension should be orthogonal to
the billable command, and it should return the fee associated with that
command. The advantage there is that you can retrieve the pricing to any
EPP command, even ones that you haven't anticipated. Otherwise you have to
model every possible variable to address the range of billable EPP commands
(via fee:action, fee:period, the phase attribute, etc.), and you'll
undoubtedly miss some. For example, some registries might want to charge a
fee for changing the registrant; or updating the info of a contact object;
or maybe an extra fee for adding more than N nameservers. I could imagine
creative uses of a variable pricing to incentivize or deincentivize all
sorts of different behaviors. Rather than trying to enumerate all possible
cases, why not just use the existing modeling of these EPP commands?

Even better would be to have two possible modes of the extension: the first
would be a "dry-run" mode that would return the fee associated with the
command, and the second would let the registrar to pass the fee with the
command and have the registry fail if the fee doesn't match the actual
billable amount. That way there can be no confusion as to what amount the
registrar is getting charged.


On Mon, Nov 4, 2013 at 3:28 PM, Gavin Brown <[email protected]>wrote:

> Hi Jan,
>
> As of version 0.3 (the 00 version I submitted to the IETF) the extension
> extends the <info> command rather than the <check> command.
>
> G.
>
> On 04/11/2013 17:54, Jan Saell wrote:
> > We have also a lot of implementations where you do a check before you do
> > any other command so check should be as light and cheap as possible.
> >
> > So ++ here also.
> >
> > Best regards
> > jan
> >
> > On 11/04/2013 04:15 PM, Luis Muñoz wrote:
> >
> >> On Nov 4, 2013, at 9:38 AM, MICHAEL W YOUNG wrote:
> >
> >>> I like the principle of extending <info>, it's in keeping with the
> concept of retrieving clarifying information, whereas <check> was meant to
> be cheap, fast, light-weight.
> >>>
> >>> There are significant cases of implementations where the underlying
> assumption is that <check> is a cheap query.  Some of which I was directly
> involved with :-)
> >
> >> ++
> >
> >> -lem
> >
> >> _______________________________________________
> >> provreg mailing list
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/provreg
> >
> >
> > _______________________________________________
> > provreg mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/provreg
> >
>
> --
> 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.
> _______________________________________________
> provreg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/provreg
>

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg