Re: [eppext] Extension Registration Request: Registry Fee Extension for the Extensible Provisioning Protocol (EPP)

Keith Gaughan <keith@blacknight.com> Thu, 06 August 2015 14:39 UTC

Return-Path: <keith@blacknight.com>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7441A899E for <eppext@ietfa.amsl.com>; Thu, 6 Aug 2015 07:39:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.099
X-Spam-Level:
X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALpbFd9eW5iD for <eppext@ietfa.amsl.com>; Thu, 6 Aug 2015 07:39:03 -0700 (PDT)
Received: from merlin.blacknight.ie (merlin.blacknight.ie [81.17.240.211]) by ietfa.amsl.com (Postfix) with ESMTP id 3733F1A87A8 for <eppext@ietf.org>; Thu, 6 Aug 2015 07:39:03 -0700 (PDT)
Received: from [81.17.243.239] (hegemon.blacknight.ie [81.17.243.239]) by merlin.blacknight.ie (Postfix) with ESMTP id 5E74333C412 for <eppext@ietf.org>; Thu, 6 Aug 2015 15:38:57 +0100 (IST)
Message-ID: <55C37181.4040409@blacknight.com>
Date: Thu, 06 Aug 2015 15:38:57 +0100
From: Keith Gaughan <keith@blacknight.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: eppext@ietf.org
References: <831693C2CDA2E849A7D7A712B24E257F49F3C5DD@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <EB6318D0-0AE1-4E98-95C6-F6EC14718952@cnnic.cn> <54DDF867.1070705@centralnic.com>
In-Reply-To: <54DDF867.1070705@centralnic.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/DcM5jbq9rlPbUV9IBl-L2Z9y5ZI>
Subject: Re: [eppext] Extension Registration Request: Registry Fee Extension for the Extensible Provisioning Protocol (EPP)
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Aug 2015 14:39:06 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A bit late to the party on this one, but I feel some registrar input is
needed.

On 13/02/15 13:13, Gavin Brown wrote:

> On 11/02/2015 02:19, Ning Kong wrote:
> 
>> #2 IMO, the extension of <check> is not necessary. It seems that 
>> the extended <check> is a little overused. I think the extension
>> of <info> is enough.

That's akin to suggesting that <check> should be dropped from EPP
itself, given its work could technically be performed with a bunch of
<info> requests.

<check> is essentially a quick path for registrars to get basic
metadata about a given set names in a single transaction. That's all
the <check> Fee extension is allowing, and that's why it's valuable.

> There has been some discussion of this point on this list; there 
> seemed to be no consensus for using <check> only or <info> only.
> In the interests of pleasing the most number of people, I chose to 
> support both.
> 
> I would be happy to revisit this question again as my personal 
> preference would be to only support one query command.

I *strongly* recommend keeping the <check> extension. For our purposes,
it's actually more useful on <check> than on <info> as we often have to
check for whether a domain is registered or not, and also its price
category to decided whether we can sell it or not. Having to rely on
<info> to get that information would mean the number of requests we
would have to make would balloon quite quickly, which would negatively
affect our ability to deal with registries using the Fee extension, and
sell such domains. If the registry supports pipelining, this is
slightly less of an issue, but pipelining support can be hit-and-miss,
and the additional overhead of using multiple <info> requests, even
with pipelining is still far from insignificant.

The overhead to the registry to support the <check> extension isn't
terribly great, and the benefits to registrars are huge.

We already have this issue with Rightside/Donuts, who require that we
do individual <info> requests to figure out if a domain is subject to
premium pricing. This impacts how quickly we can get results back to
a customer as the results are rarely worth caching, and even under the
best of conditions, the customer gets their results back more that two
or three times slower for those domains than their otherwise would if
the information was returned in <check>.

K.

- -- 
Keith Gaughan, Development Lead; PGP/GPG key ID: D5FC9D23
Blacknight Internet Solutions Ltd. <http://blacknight.host/>
12A Barrowside Business Park, Carlow, R93 X265, Ireland
Registered in Ireland, Company No.: 370845
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJVw3GBAAoJEMrbaevV/J0jTUoQAJcqwiJ6dCYJWGHC2RDrt9TS
xCU88t9ikNtX6Zx9JrkxB1xy1UFTvPhxYrrPS4nh1vw6cL+4vO40hOqPwXGrbOF2
oClxA8K7tflTMNvzspC0MpiS6YVEzrgmkMQcMfhFL41gKExsgTXmdWXw9Fz6AQbm
P+sbiF75IcSAicXVH4DSqYkk4eftKjtl0woH/GGjFce5lDf4EeDh7xC3XTLrWr5p
a5/9kmgSDs4a23V4GoX18s3BAIzAYpqckjTfeORegdRoTc1TuzQ4OL2mkZZoVxNQ
xHP0y6jDMWehUA7IfraxX/C6fgYSqK9HbbEyzEdi2T9TJLApsEQL3MSKeMWZW69l
T8qSlBFko1qox3PgrFOLdrpZph2a+nm8qKILZPEU6vMi15veiBZtJaj9vWdAxQQj
aBkL5bbna2kuRuxd51IAUY55rdLOLZ2ay2aKU6EcgiYlt7/PLZgLim8mzd0lVKuW
lyMo+9xIlQqEmk+DmHs+betSp71nfS9JAXM+/CZAnd1K8veDin/Bj4b/z99dSNoz
28j7XsxqT3sjLLeNVd1xWYxvpxdkPh6Ue+C1fe1h7MmyY8ERNhXm2nENQEk83cEs
5XmY7C+L6Y8WWXgsj9GX0bT05YpYwXGoA+HNsyStsE1x0ah6GrGaVqT+5btwzijm
mmYXWXurAbE3sUyIV1HW
=0Zpr
-----END PGP SIGNATURE-----