Re: Registry Fee Extension for the Extensible Provisioning Protocol

Gavin,

My feedback is below.

-- 
 
JG
 

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




On 11/1/13 6:12 AM, "Gavin Brown" <[email protected]> wrote:

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

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.


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


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.

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

Yes, that is a good idea.

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

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.


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