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-----
- [eppext] Extension Registration Request: Registry… Hollenbeck, Scott
- Re: [eppext] Extension Registration Request: Regi… Ning Kong
- Re: [eppext] Extension Registration Request: Regi… Alexander Mayrhofer
- Re: [eppext] Extension Registration Request: Regi… Gavin Brown
- Re: [eppext] Extension Registration Request: Regi… Gould, James
- Re: [eppext] Extension Registration Request: Regi… Keith Gaughan