Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol

From: Gavin Brown <[email-masked]>
Date: Fri, 01 Nov 2013 10:12:07 +0000

Hi Jim,

>  1. Why extend the check instead of info (e.g. fee info)?  

Because if the object doesn't exist, the server would have to return a
response with a 2303 error, and an <extension> element. While this is
permitted, my guess is that most EPP client libraries would see the
error first, and therefore would require a special case in order to
provide the extension data to the consuming application.

Also, by extending the <check> command, you avoid multiple round-trips:
the client can query availability and the fee for a <create> in a single
command.

>  2. How about supporting the use of the extension with the billable
>     commands themselves as well, where the client can ask for the fee
>     information and the server can return the information in the
>     response upon successful execution?  

That's potentially useful, but my belief was that clients would
generally prefer to know the cost of a transaction *before* submitting
it, rather than after it had been received by the server. It would still
be desirable to include the fee information in the response however, to
cover the edge case where the fee had changed since it was last checked.

>  3. It would be good to support a more flexible set of commands, like we
>     support the concept of sync (consolidate extension) that is also
>     billable.  There might be other billable commands.

This could be achieved by changing the <fee:action> to allow any token,
dictated by server policy.

>  4. The fee could have an optional breakdown as well, where some
>     billable commands include a fixed fee plus another variable fee
>     (e.g. based on period extended).  The total fee should obviously be
>     a total of the more detailed fees.  The type of fees might need to
>     be flexible as well to support various billing models.  The
>     Registrar might only be interested in the resulting fee, but having
>     the breakdown could be useful. 
>
>  5. The client might be interested in any variable pricing based on
>     periods.

The extension isn't designed to allow clients to enumerate the server's
fee structure, just to determine the fee associated with a given
transaction: this is in line with EPP's status as a provisioning
protocol rather than a general purpose information-sharing system.

G.

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

---

From: Gavin Brown <[email-masked]>
Date: Fri, 01 Nov 2013 10:17:57 +0000

On 31/10/2013 18:52, Luis Muñoz wrote:
> 
> On Oct 31, 2013, at 1:31 PM, Gould, James wrote:
> 
>> 	• It would be good to support a more flexible set of commands, like we support the concept of sync (consolidate extension) that is also billable.  There might be other billable commands.
> 
> I agree to this. Creating launch applications, for example, could be something to add as well.

Wouldn't the fee for the launch application simply be the <create> fee?
I suppose an optional "phase" attribute could be added to the
<fee:action> element, e.g.:

<fee:action phase="sunrise">create</fee:action>
<fee:action phase="landrush">create</fee:action>

> While responding in an ISO 4217 currency works well, there should also be support to respond in opaque or internal value representations. It is conceivable that an EPP server is currency agnostic, instead working with internal currency units.

ISO 4217 includes the special purpose "XXX" code for non-currency
transactions. I think this would suffice for this purpose, but the draft
could be updated to specifically refer to it.

G.

---

From: MICHAEL W YOUNG <[email-masked]>
Date: Fri, 1 Nov 2013 09:29:03 -0400

Hi Gavin,

I'd rather leverage the extension off of the info command and expect the sequence used would be check the info <extension> to see if a domain is available and then check its price.

Why?

The principle of the check command originally was to keep a very cheap command just to verify availability.

In those registries that drop their domains in sequence (versus all at once), the check command is a cheap command that allows registrars competing for a dropped name to verify availability before they trigger a create. (much better than add storms)

Now I know we are talking about an optional extension, but if you want to not have this spiral, then I think you put the extension elsewhere.

We are talking about retrieving clarifying information and it just makes sense that goes under domaininfo (although I totally understand your efficiency argument Gavin, but I think that particular optimization is at the expense of organization)

All Best

Michael Young

On 2013-11-01, at 6:12 AM, Gavin Brown <[email-masked]> wrote:

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

MICHAEL W YOUNG
[email-masked]

---

From: Luis Muñoz <[email-masked]>
Date: Fri, 1 Nov 2013 12:08:37 -0400

> <fee:action phase="landrush">create</fee:action>

Yes, but the sub-phase should be added as well. Perhaps

<fee:action phase="custom" subphase="mumble">create</fee:action>

The subphase attribute could be made optional as perhaps the most common use cases won't require it.

> could be updated to specifically refer to it.

Ah, excellent. Yes, I think this is a good mechanism to convey this information.

Best regards

-lem

---

From: Gavin Brown <[email-masked]>
Date: Fri, 01 Nov 2013 16:31:08 +0000

> The subphase attribute could be made optional as perhaps the most common use cases won't require it.

I'll add this to the next version.

G.

---

From: "Gould, James" <[email-masked]>
Date: Fri, 1 Nov 2013 19:10:26 +0000

Gavin,

My feedback is below.

-- 
 
JG

James Gould
Principal Software Engineer
[email-masked]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

>the client can query availability and the fee for a <create> in a single

I see this a fee info and not either a domain info or a fee check.  A
domain info with the fee extension could be defined as a fee info command
and return the EPP response (not the domain info response) with just the
fee extension similar to the claims check command and response in
draft-tan-epp-launchphase.  I don't recommend merging commands to reduce
round trips, but to create commands for specific well defined purposes.
The extension of an existing verb to define a new verb (e.g. update
extension for restore or check extension for claims check) has been used
in the past and I believe can be used here.

>cover the edge case where the fee had changed since it was last checked.

Yes I see both cases, since the price might be a factor prior to sending
the billable command, while returning what the fee was in the billable
command response would help ensure that the right price was charged.

>dictated by server policy.

Yes, that is a good idea.

>protocol rather than a general purpose information-sharing system.

I see this as a real grey area, since you could have a targeted info
command for the fee for a specific period or you could have a info command
for the fee information of an individual billable command.  Knowing
whether or not there are different fees based on a range of periods may be
useful as well.  I don't imagine that the ranges will be that many, where
most will consist of a single range (e.g. Fee X per year from 1 to 10 year
periods).  The default could be all periods, but supporting multiple
variable fees with optional period range values and an optional fixed fee
value could be supported.

---

From: Gavin Brown <[email-masked]>
Date: Mon, 04 Nov 2013 13:16:14 +0000

On 01/11/2013 19:10, Gould, James wrote:
> I see this a fee info and not either a domain info or a fee check. [snip]

I am now agnostic on whether to use <info> or <check> for this extension
(having previously been in favour of <info>). When I originally wrote
the predecessor to this extension back in 2011, I did have some
reservations about which command to use, and spoke to Patrick Mevzek who
(at the time) agreed with my decision to use <check>.

If anyone else has thoughts about the choice of command to extend,
please speak now!

> command response would help ensure that the right price was charged.

The latest version adds elements to the responses for <create>, <renew>,
<transfer> and <update>.

> Yes, that is a good idea.

I have an update in the pipe which changes <fee:action> to a token. The
text of the draft requires servers to support the basic EPP command set
as a minimum, plus "restore" if RFC3915 is implemented.

> value could be supported.

I suppose the <fee:fee> element could be allowed to have multiple
occurences, each with a description. For example:

   S:        <fee:chkData xmlns:fee="urn:ietf:params:xml:ns:fee-0.3">
   S:          <fee:domain>example.com</fee:domain>
   S:          <fee:currency>EUR</fee:currency>
   S:          <fee:action phase="sunrise">create</fee:action>
   S:          <fee:period unit="y">3</fee:period>
   S:          <fee:fee desc="Base fee">2.50</fee:fee>
   S:          <fee:fee desc="Sunrise application fee">10.00</fee:fee>
   S:          <fee:fee desc="Multi-year discount">-2.50</fee:fee>
   S:        </fee:chkData>

The client would determine the final fee by totalling the value of each
<fee:fee> element.

Servers would be under no obligation to send more than a single
<fee:fee> element, but could do so if desired.

G.

---

From: MICHAEL W YOUNG <[email-masked]>
Date: Mon, 4 Nov 2013 09:38:25 -0500

I weighed in earlier but it might have been lost in the noise

> If anyone else has thoughts about the choice of command to extend,

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 :-)

-Michael Young

---

From: Luis Muñoz <[email-masked]>
Date: Mon, 4 Nov 2013 10:15:02 -0500

> 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

---

From: Jan Saell <[email-masked]>
Date: Mon, 04 Nov 2013 18:54:33 +0100

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

>> 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 :-)

- -- 
+-------------------------------------------------------------------
! Irial / YASK AB
! Att: Jan Saell
! Box 59, S-692 21 KUMLA, SWEDEN
! Tel: 019-58 25 15     Int +46-19 58 25 15     Fax +46-19 58 38 05
! E-mail: [email-masked]
! PGP Fingerprint: E957 23C8 9F51 0958 B9AD  7F18 404A 5DA1 F944 A08B

---

From: Gavin Brown <[email-masked]>
Date: Mon, 04 Nov 2013 20:28:23 +0000

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.

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

---

From: Patrick Mevzek <[email-masked]>
Date: Mon, 04 Nov 2013 23:16:40 +0100

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

The check can remain as light as it is today… since the fee structure is
returned only if the fee extension is added in check command, so it is
totally up to the registrar to see if they want it or not and if they
want the super fast check without it or the heavier one with it.

I have no strong opinion either way (and did not have time to
extensively read the new extension proposal), but I still slightly
prefer the check for this reason:
my reading of the spirit of EPP is that "info" is to query data about an
existing object in the registry database. In that way, a fee is not an
object, and neither a property of a domain (it is a property of a
transaction, not of a live object of a registry database)

Hence, the need to do a domain:info on a *non-existing* yet domain name
to find the cost of this creation is troublesome for me.

While §2.9.2.2. of RFC530 can be read in many ways, I'm assessing it as
"resData is there only in case of success" (and hence also <extension>).
I do also read exactly in the text:
The EPP <info> command is used to retrieve information associated
   with an existing object. 

So domain:info prior to a creation seem counter-nature to me

-- 
Patrick Mevzek

---

From: Seth Goldman <[email-masked]>
Date: Mon, 4 Nov 2013 17:29:31 -0500

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-masked]>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
> >

---

From: MICHAEL W YOUNG <[email-masked]>
Date: Mon, 4 Nov 2013 17:33:20 -0500

> So domain:info prior to a creation seem counter-nature to me

Interesting point, however,

Same principle applies with <check> , if the domain doesn't exist in the registry and you send back pricing information it's a query for information about a non-existent domain object.

Both <check> and <info> are referring to a domain object if it exists and returning information (pricing) regardless if the domain object doesn't exist.

So, really, if anything, that supports the argument for new commands,........and new objects (a pricing object) - now watch everyone groan on the list.

-M

MICHAEL W YOUNG
[email-masked]

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 05 Nov 2013 00:20:51 +0100

Le lundi 04 novembre 2013 à 17:33 -0500, MICHAEL W YOUNG a écrit :
> Same principle applies with <check> , if the domain doesn't exist in
> the registry and you send back pricing information it's a query for
> information about a non-existent domain object.
> 
Yes, but domain:check is tailored to operate on both existing and
non-existing domain names per definition, while for me domain:info is
not.

Same problem with the launchphase extension during claims phase.

> So, really, if anything, that supports the argument for new
> commands,........and new objects (a pricing object) - now watch
> everyone groan on the list.

I was in fact about to suggest a "fee" object, but I sense it to be not
worth the hassle, and have no time to work on that.
I will implement the currently discussed draft both in the check or in
the info command, I have no strong enough opinion.

-- 
Patrick Mevzek

---

From: Gavin Brown <[email-masked]>
Date: Wed, 06 Nov 2013 12:37:49 +0000

On 04/11/2013 22:29, Seth Goldman wrote:
> 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 latest version does this - see Section 2.2 of the draft published on
the IETF website.

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

I was contacted off-list by another registry who have implemented an
extension very similar to mine. Their extension provides a mechanism
whereby the client includes the expected fee (previously obtained by
performing a lookup) in the command. The server can then reject the
command if the fee submitted does not match what it calculates it to be.

This ensures that both client and server agree what the fee for the
transaction is, before it takes place.

I very much like this idea and am planning on incorporating it into the
next version of my draft.

G.

---

From: Maarten Bosteels <[email-masked]>
Date: Wed, 6 Nov 2013 13:55:07 +0100 (CET)

See also the EPP extension by ARI: http://ausregistry.github.io/doc/price-1.0/price-1.0.html 
which is also mentioned here: http://ariservices.com/registrars/ari-registry_implementation.pdf 

Maarten 

----- Original Message -----

| From: "Gavin Brown" <[email-masked]>
| To: "Seth Goldman" <[email-masked]>
| Cc: "EPP Provreg" <[email-masked]>
| Sent: Wednesday, 6 November, 2013 1:37:49 PM
| Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning
| Protocol

| On 04/11/2013 22:29, Seth Goldman wrote:
| > 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 latest version does this - see Section 2.2 of the draft published on
| the IETF website.

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

| I was contacted off-list by another registry who have implemented an
| extension very similar to mine. Their extension provides a mechanism
| whereby the client includes the expected fee (previously obtained by
| performing a lookup) in the command. The server can then reject the
| command if the fee submitted does not match what it calculates it to be.

| This ensures that both client and server agree what the fee for the
| transaction is, before it takes place.

| I very much like this idea and am planning on incorporating it into the
| next version of my draft.

| G.

| --
| 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-masked]
| https://www.ietf.org/mailman/listinfo/provreg