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

From: Gavin Brown <[email-masked]>
Date: Thu, 31 Oct 2013 16:51:40 +0000

Dear colleagues,

As the I-D submission window is closed, I am unable to submit this to
the IETF, but I plan to do so once the submissions re-open.

https://raw.github.com/centralnic/epp-fee-extension/master/draft-brown-epp-fees.txt

I would like to request that this be considered for adoption by the
eppext group.

>From the introduction:

Historically, domain name registries have applied a simple fee structure
for billable transactions, namely a basic unit price applied to domain
<create>, <renew>, <transfer> and RGP restore commands.  Given the
relatively small number of EPP servers that EPP clients have been
required to connect to, it has generally been the case that client
operators have been able to obtain details of these fees out-of-band by
contacting the server operators.

Given the imminent expansion of the DNS namespace, and the proliferation
of novel business models, it is now desirable to provide a method for
EPP clients to query EPP servers for the fees associated with certain
commands and specific objects.

This document describes an extension mapping for version 1.0 of the
Extensible Provisioning Protocol (EPP) [RFC5730].  This EPP mapping
provides a mechanism by which EPP clients may query the fees associated
with various billable transactions.

You can fork the draft and push changes to me from here:

https://github.com/centralnic/epp-fee-extension

Regards,

-- 
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: Rubens Kuhl <[email-masked]>
Date: Thu, 31 Oct 2013 14:56:58 -0200

Gavin,

Although ccTLDs operate on their own regulatory framework, the fact that renew and transfers are ICANN-regulated to be of equal value would probably lessen the interest of the community in having variable fee <renew> or <transfer> operations. 
In this case I need to ask if there are enough ccTLDs that both operate on registry-registrar model and allow for <renew> and <transfer> prices be based on some kind of premium status… 

Rubens

Em 31/10/2013, à(s) 14:51:000, Gavin Brown <[email-masked]> escreveu:

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 31 Oct 2013 16:56:58 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Gavin Brown
> Sent: Thursday, October 31, 2013 12:52 PM
> To: [email-masked]
> Subject: [provreg] Registry Fee Extension for the Extensible
> Provisioning Protocol
> 
> Dear colleagues,
> 

We don't yet have an eppext working group; Pete has said that he intends to start the chartering process soon. It would be a good course of action to watch for the charter proposal announcement and add this request as a comment on the proposal when the window of opportunity opens.

Scott

---

From: "Gould, James" <[email-masked]>
Date: Thu, 31 Oct 2013 17:31:49 +0000

Gavin,

It looks like an interesting idea.  I do have the following comments / feedback:

  1.  Why extend the check instead of info (e.g. fee info)?
  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?
  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.
  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.

We had created a Price Extension a while back that extended the domain info command and response along with the other billable commands (create command/response, renew command/response, transfer command/response, and update command/response for billable extensions to update like restore or sync), with the following elements:

  *   Domain Info
     *   Command
        *   Command Name
        *   OPTIONAL desired period
     *   Response – The idea is that a specific period could be returned or the entire table of period pricing would be returned.
        *   One or more priceData elements containing
           *   Start period (.e.g starting with 1 year or 3 year period)
           *   End period (e.g. end with 2 year or 10 year period)
           *   Price type (e.g. regular or promotion)
           *   Eligible – Is client eligible for promotion pricing
           *   Amount – Price amount
  *   Create, Renew, Transfer, and Update (for restore and sync)
     *   Command
        *   Marker to indicate that price information should be returned in response
     *   Response
        *   Price type (e.g. regular or promotion)
        *   Amount

One other command that would be interesting is creating an extension to delete command / response to return any grace period credit information.

--

JG

James Gould
Principal Software Engineer
[email-masked]

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 10/31/13 12:51 PM, "Gavin Brown" <[email-masked]<mailto:[email-masked]>> wrote:

Dear colleagues,

Regards,

[email-masked]<mailto:[email-masked]>

---

From: Luis Muñoz <[email-masked]>
Date: Thu, 31 Oct 2013 14:52:43 -0400

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.

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.

Best regards

-lem