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

Patrick Mevzek <pm@dotandco.com> Tue, 14 July 2020 16:12 UTC

Return-Path: <pm@dotandco.com>
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 9953E3A0971 for <regext@ietfa.amsl.com>; Tue, 14 Jul 2020 09:12:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dotandco.com header.b=NGK3Rtgp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NcFSK7eV
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 gLsB2M06cT1A for <regext@ietfa.amsl.com>; Tue, 14 Jul 2020 09:12:56 -0700 (PDT)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 810E43A091E for <regext@ietf.org>; Tue, 14 Jul 2020 09:12:56 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 93BC18F2F for <regext@ietf.org>; Tue, 14 Jul 2020 12:12:55 -0400 (EDT)
Received: from imap22 ([10.202.2.72]) by compute3.internal (MEProxy); Tue, 14 Jul 2020 12:12:55 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dotandco.com; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=NQfyKetjvhZEru29XmVPAURqn5jW4sl 0FI7S5fyrsIs=; b=NGK3RtgpQ45cQMe88l58s8XtiuFFMjmv/pez/dCWSXbk3li BWG6967d46qPyrC2WSl4c44VZrqNmUpFx1glsmUsvhSfSxQ1DdoWoMgV2ozQRJf2 6jRYxeJ9uPeaL+5h/k8WLm70NpopiUp8jQhTZsSbrlz9+Tes7rhmjfnNzJQlStVE 7Yy9jH1wKa6SstMBzWKW5pMd+c2vwh95Gis+0IkVCHtSfmyTf7l8+W2mASXxSnQH Jh5DVvPqynVGpojwpgvmfjsPscc3Ah4ODlAYs0nBJL0iFTJ3C7Wx1Rvev0nOTT17 i1x6cnZotZxR+DbNKRMBlGgHRtUW/sDnup0tykA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=NQfyKe tjvhZEru29XmVPAURqn5jW4sl0FI7S5fyrsIs=; b=NcFSK7eVt0AmoDR7jljz05 6u5MSUZcxa+bnOjS/pcqTY3KevwsuxDfYHFyJqW3xi+KFY1y2rnNJ62c6xDKCYzd jIXtIB90Cxn2/nSEp6hGn1c/DgNWTcFaNmjfhsAsZgm5yLQ8lML7wNjV9XJ0eVu/ DZOd0quegpPxjiK2dLbEggIoAp5aPfRsGPGll7UFgoKcoHKURBdJyFK1K5815KpK FtWcqZ0AMu24M2+4N/zPhUJ34J0warciWbeKATbKhbgI60h1Q48xwOakxKkrhTLY nZc5kF0PMI0gFuWhCqDoM1jgR6Y1O6ftF1crlUPzZHq+pdlFvsAin+RORcSosH2Q ==
X-ME-Sender: <xms:htkNXxArI-m9fTW4WMXCUqdrBGuguUHpGtAUJHa_Ic4ylk3tqHRxxEdqG5w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfedtgddutddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfrfgrthhrihgtkhcuofgvvhiivghkfdcuoehpmhesugho thgrnhgutghordgtohhmqeenucggtffrrghtthgvrhhnpeefueeuieefffdvleeuvefhte dugfehjeevjeetfeduhfevgfeltdfhgeehjeehveenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehpmhesughothgrnhgutghordgtohhm
X-ME-Proxy: <xmx:htkNX_jRX7fzsMfHfYyKzM1dNOXBtu3B96QVQAepPmTeTm5ubnZ-OQ> <xmx:htkNX8mOccI8U5EaTIRdg_fT3pLZoFcgXhXjSYSUvFJho_TZxW1jzQ> <xmx:htkNX7zN0QS7zkaHU-nfsgsYNOlp3P1iNpOVxsS19eqdYPMcpj62uA> <xmx:h9kNX0AYxPjdpybZS6XvLA5M1HBF3usun1J-zXUi73s_SBGN_XRbgQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id AF0BD6680078; Tue, 14 Jul 2020 12:12:54 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-613-g8a73ad6-fm-20200709.001-g8a73ad6e
Mime-Version: 1.0
Message-Id: <5d534f8b-08e9-42e6-afa3-1527a81e5fe0@www.fastmail.com>
In-Reply-To: <7b414e33-2d8e-ff9e-3ad2-307cbcaa1c0e@knipp.de>
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> <7b414e33-2d8e-ff9e-3ad2-307cbcaa1c0e@knipp.de>
Date: Tue, 14 Jul 2020 11:12:33 -0500
From: Patrick Mevzek <pm@dotandco.com>
To: regext@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/iHFeejTSc1ldsM2W93AxtXsxQLc>
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 16:12:59 -0000


On Tue, Jul 14, 2020, at 10:48, Thomas Corte (TANGO support) wrote:

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

Can work both ways: registrars could in the same way put pressure on registries
to implement new version otherwise they can threat to stop selling their premium
names.
There are even various industry groups where such subject could be tackled on
non-technical aspects of it
(but then for "fee" it is a little more complicated because this is related to prices,
and various jurisdiction have laws prohibiting competitors to discuss in private
circles anything that could be related to price issues, in order to make sure the market
remains non-captive and really competitive).

But that is kind of shooting themselves in the foot if the registry does not go
forward (and the registrar really stop using the old version), as it would be for
a registry to stop providing an old version for real even if some of its smaller
registrars do not support the newest one.

Like BCP38, changes like that provide not null but minimum benefit to the actor
of the change, while it provides huge benefit to the whole ecosystem.
(the last one transitioning and finally removing the old version completely from
all systems may be even the one with the highest benefit to the community).

But in short, no one gets benefit of starting first.
Hence, outside forces need to come into play to tilt the current balance.

-- 
  Patrick Mevzek
  pm@dotandco.com