Re: [regext] EPP Registry Fee Extension: availability check result depending on fee extension?

"Thomas Corte (TANGO support)" <Thomas.Corte@knipp.de> Tue, 14 July 2020 15:48 UTC

Return-Path: <Thomas.Corte@knipp.de>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2433A08C7 for <regext@ietfa.amsl.com>; Tue, 14 Jul 2020 08:48:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 SwCH53ubJS5n for <regext@ietfa.amsl.com>; Tue, 14 Jul 2020 08:48:55 -0700 (PDT)
Received: from kmx5a.knipp.de (kmx5a.knipp.de [IPv6:2a01:5b0:0:29::63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDC273A08BB for <regext@ietf.org>; Tue, 14 Jul 2020 08:48:54 -0700 (PDT)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx5a.knipp.de (Postfix) with ESMTP id 4B5lLD0f6gz4vCM; Tue, 14 Jul 2020 17:48:51 +0200 (CEST)
Received: from dhcp203.intra.dtm.knipp.de (dhcp203.intra.dtm.knipp.de [195.253.2.203]) by hp9000.do.knipp.de (Postfix) with ESMTP id BA4D671996; Tue, 14 Jul 2020 17:48:51 +0200 (MESZ)
To: regext@ietf.org
References: <20200314164521.0B10EF406C9@rfc-editor.org> <ac9d9567-e847-8802-14e4-07c36e216c19@knipp.de> <5703B97E-20EF-4FCA-AA32-68AF595A088F@verisign.com> <04d5dfb5-d9ae-06a9-b137-4cedcefbc399@knipp.de> <9EF7EBBA-9E2E-4478-9F5B-1AC3C50191C5@verisign.com> <5f1f0f3f-d801-3591-68b6-f9ee044e3305@knipp.de> <36C57CBC-D931-4B87-B4DE-27A75CA28E38@verisign.com> <5f93bb04-16fd-8a9c-9a79-4a225e5d9563@knipp.de> <40207ACB-3CC2-4481-829E-86C37BDA530A@verisign.com> <123689b4-9bb1-eaf6-9ecf-3d49ab343f7d@knipp.de> <42b326fe-a123-483f-bfde-641cdd1d2301@www.fastmail.com>
From: "Thomas Corte (TANGO support)" <Thomas.Corte@knipp.de>
Organization: Knipp Medien und Kommunikation GmbH
Message-ID: <7b414e33-2d8e-ff9e-3ad2-307cbcaa1c0e@knipp.de>
Date: Tue, 14 Jul 2020 17:48:51 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <42b326fe-a123-483f-bfde-641cdd1d2301@www.fastmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spamd-Bar: /
Authentication-Results: kmx5a.knipp.de; none
X-Rspamd-Server: v1117
X-Rspamd-Queue-Id: 4B5lLD0f6gz4vCM
X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:8391, ipnet:195.253.0.0/16, country:DE]; LOCAL_WL_IP(0.00)[195.253.2.54]
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/_1uExE7NzqNmk5nmdbgnPA-uDuQ>
Subject: Re: [regext] EPP Registry Fee Extension: availability check result depending on fee extension?
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jul 2020 15:48:57 -0000

Hello,

On 7/14/20 17:21, Patrick Mevzek wrote:

> It is a classical chicken and egg problem based on the fact that registries, once they got one version working have no or very little incentive to change (being similar as other registries is not a strong force for them) and for registrars as long as not all registries do the same thing they have anyway to code for the extra case and then once they done it for one registry they could as well use that for others. So for registries they have only one case to handle, where registrars have many but for registries each registrar is like any other, besides its market position eventually.
> 
> However, for a non trivial number of players in this game they are bound by contracts that
> can basically force them to implement new standards after some given delay.
> But that wouldn't apply for ccTLDs where each registry is king in its kingdom.

True, and even for gTLDs, there is no real pressure here since ICANN
doesn't seem to be particularly aware of the EPP fee extension (or care
about interoperability with regard to domain price tiers for that
matter). But that may (and should) change, of course.
> Besides market pressure, that has its limits here, I see only contractual forces able to move things around.

It could go a long way if some of the larger registries (Verisign,
Afilias, Neustar, CentralNic, Donuts) would care to implement the RFC
version *and* start to phase out the older versions with clear deadlines.

As long as they keep supporting ancient versions of the extension (or, in
the case of Donuts, use their own proprietary one), the larger registrars
will see no incentive to implement newer versions, and will in turn
pressure smaller registries into adding support for these ancient
versions (e.g. by threatening to otherwise not include their premium
domains in their portfolios).

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbH                    Thomas Corte
Technologiepark                             Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9                       Fax: +49 231 9703-200
D-44227 Dortmund                      E-Mail: Thomas.Corte@knipp.de
Germany