Re: [regext] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?
"Gould, James" <jgould@verisign.com> Tue, 14 July 2020 13:10 UTC
Return-Path: <jgould@verisign.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 F37473A0064 for <regext@ietfa.amsl.com>; Tue, 14 Jul 2020 06:10:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, 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=verisign.com
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 pUrkK7F8bsW1 for <regext@ietfa.amsl.com>; Tue, 14 Jul 2020 06:09:59 -0700 (PDT)
Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.31]) (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 24EFE3A0063 for <regext@ietf.org>; Tue, 14 Jul 2020 06:09:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=8742; q=dns/txt; s=VRSN; t=1594732199; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=46LcU6WjjleHMQXqvwyrk335T8IItFz0jyOdizpgHiw=; b=ZOB4u8PpLpT8LB4jJCitwkNAOR8bVXleuHVualufhNPc+3yP4H87ejuh KwP/VI07Amo9yr8pgt8oG6NMoigBJgKtZF5xKzGd1Xjbhe7fxHjG79xUb zbez+eWjDHyoqYH2IB2X5TB+aSwmrpZvIkNEoKE6QUNoIh6VtxHplG4Y2 k6txUDsc2T/eBhRnW33x+jp32aV5IG6LuzhJU41hHiubzB635+8L+Xtvg LwiZx1ZTGBuVwijX8L5WPq3gWPR0J8Km1nAUplGBsHJQMQTbKQCRjKv6z lbgRXtSdUg0zG4A0upA8RUwQV0F/neIBM/rA0447hyIxJ2lRGY5uquMV2 A==;
IronPort-SDR: Jdw3OzrQEgcU0MpsrKpHQx3nIDMSyeD4q3gNrjjYGredyfbWgdZCUi2POTFd0+k7ocTDrkW4ml M000dgARrT/jjfnVyxFeFWB4QuZZ//gooSibOhUVa9VYkU061y7tftAZBenqeN9LMIgKImXsBA XRdU0jWrTGci0e0DnzlJlcxf0DRLeh+3VDwFbUyosR0Md+Z6k5LuOBv7CWvBoBVC1W7p5VQw/P MVoErvfRWzaZFRDnDhIvCDOy8FFEMRE8hPXp6lTpEyDm+0/wKVITRR/olRmCAu+ppXlbkRPkca MMc=
X-IronPort-AV: E=Sophos;i="5.75,350,1589256000"; d="scan'208";a="2117953"
IronPort-PHdr: 9a23:ycha+xNn1i3aQoGLPegl6mtUPXoX/o7sNwtQ0KIMzox0K/36o8bcNUDSrc9gkEXOFd2Cra4d1ayN6+u+ACQp2tWoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7Ovr6GpLIj8Swyuu+54Dfbx9HiTagYL5+Nhu7oRneusQXnIdpN7o8xAbOrnZUYepd2HlmJUiUnxby58ew+IBs/iFNsP8/9MBOTLv3cb0gQbNXEDopPWY15Nb2tRbYVguA+mEcUmQNnRVWBQXO8Qz3UY3wsiv+sep9xTWaMMjrRr06RTiu86FmQwLuhSwaNTA27XvXh9RwgqxFvRyhuxJxzY3aYI6XOvV+f7/Sc9wVSmdaQsZeTClBDp+gY4YVDecMO/tToYnnp1sJqBuzHQegCuLoyj9Vgn/5wLU22PklHw7c2QwvAckOvHrJp9jyNqcSXue1zLTMzTredP5Wxyny6JLJchA6oPGMUrRwfdDNxkkoEgPIl1OdopHqMD2JzOoCqXSb7/Z+WuK1jW4qswN8rzeyy8syloTHiYMYx1DH+Ch9z4g5ONO2RUF7bNK4HpZcqi6UOoRrT84tXW1ltzg3x6MbtJO7ciYEyIgrywDZZveafYaI5RfjW/yQITd+nH9lZqywhwyz8Ui7y+38Wc+00FdMriVZiNXDqncN1xnL5sebS/t95Vuu2TGV2w/P7eFEJFg4lavFJJ49zL48jJ0TsV7MHiLwhU74j7eWe1059uS08ejrf7frq5GGO4NpigzzPL4il8O7DOggLwQCQ3KX9fm+2bH/50H1XbpHg/4snqXEs53XI9kQqLSjDA9PyIkj7g6yDzKh0NsFg3YKNElFeBebj4jxPFHOPez4Ae+/g1uylDdrwOjLM6D9DJvVM3TMkK/vc7l85EJA1gY/185f6I5TCrEbOPL/QFX+u8HCAh8nKQy02ODnBM9h2YMZXGKDGq6ZMKXMvl+U/u8jPvWAaJUItDv/JfUp/ePigH83lFMHcqSk2YMbaHWiEfRnJ0WZb2DsgtAEEWoSvAo+Q+vqiECGUTFOfHuyQbwz5is6CIK9DIfDSYatjKad0ye8G51afnpGBUyUEXf0a4WEXO8BZjySIs9mlzwLT6OhR5U/2BGprg/616RoI/HX+i0etJLjzMB16/fOmh4s7TZ0FdiS03mRT2FomWMFXyU2075woUNjxVaDzbN1g/1GGtxP6fNFSAA6NYTTz+ZiEdD9RhrBfsuVSFahWtimGiwxTsopw98JeUZ9B86vjgzZ0CqsDL8VkKWHBIYv8q7Gw3fxIMN9mD760/xrs1khR8JUc0ahnLJy3wvVBpbR1UmU3e7+SaQb2SfWskyE13aDlEJeURZoF6nICzRXLFHbotnp+mvDQqOgT7M9PUEJndSPJaZadvXogElIAvD5N4KNTXi2njL6KhGVwr/IJKjjfmgGlm2JCkcDjgQf1WiLLwklByin5WnZCWo9RhrUf0rw/Lwm+zuARUguwlTSYg==
X-IPAS-Result: A2H6BACqrQ1f/zGZrQpdAx4BAQsSDECDP4EkgTMKhCmRG4Nzli2BLD0LAQEBAQEBAQEBBwEfEAQBAQKESgIXgXElOBMCAwEBCwEBAQUBAQEBAQYDAQEBAoYXBicMgjcieD0JPQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQUCCAdNB0cBHwEEASMROgsOAgIBCBoCHwcCAgIZFxUQAgQBDQWDJgGCXKlLgTKKcAWBCSqFOUc/hk2BQj6BESccgk0+gQSDHwIJDxcKJoJPM4ItBI8NgzeGb5tyAweCXYhTkQoehBSbIJFxiEYSgUyQMoQhAgQCBAUCFYFqgXtwFTsqAYI+CUcXAg2MG4IbH4M6ilZ0DiYDAgYBBwEBAwmOCIEzgREBAQ
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 14 Jul 2020 09:09:57 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%6]) with mapi id 15.01.1913.005; Tue, 14 Jul 2020 09:09:57 -0400
From: "Gould, James" <jgould@verisign.com>
To: "Thomas.Corte@knipp.de" <Thomas.Corte@knipp.de>, "regext@ietf.org" <regext@ietf.org>
CC: "support@tango-rs.com" <support@tango-rs.com>
Thread-Topic: [EXTERNAL] Re: [regext] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?
Thread-Index: AQHWS8BAxPyuP9a+wUiwqG3Zbf/+Y6jq8cYAgBX4LgCABRsxgIABL08A///hDICAAEoIgP//yRyA
Date: Tue, 14 Jul 2020 13:09:57 +0000
Message-ID: <CC241BF2-F2E0-4EF1-AC15-29264D3AA897@verisign.com>
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>
In-Reply-To: <123689b4-9bb1-eaf6-9ecf-3d49ab343f7d@knipp.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.16.200509
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <0D7D522FA581E44DB39CF474E5A8213D@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/iMBXzSlg_k9cnXBr-aUHwbEYMjU>
Subject: Re: [regext] RFC 8748, 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 13:10:01 -0000
Thomas, > By the way, you're right that fee-0.8 is very old, however you'd be > surprised that, for many registries, it is still the latest version they > will support, with some only supporting even *older* versions (like > fee-0.5 in the case of CentralNic). > This has led to the unpleasant situation that some bigger registrars who > want to avoid the effort of implementing newer versions even put pressure > on registries to introduce support for these older versions, as they > regard them as the established "de-facto" standard. > > Based on this experience, I'm afraid it will take a long time until > fee-1.0 will be widely adopted by registries or registrars, if ever. You bring up an interesting topic of the practice that we've been following with using pointed schema versions (e.g., 0.5, 0.8, 0.11) up until a draft completes WGLC, which then bumps the schema to 1.0. In the past the schema versions were set to 1.0 and non-backward compatible changes were not isolated, which is fixed by the pointed version practice. If servers and clients lock in on particular pointed versions, then it puts upgrading to the RFC version (1.0) at risk. I hope that clients would apply pressure for servers to implement to the RFC once it's published, which should consolidate the implementations to a single version. The pointed versions should be deprecated and removed over a period of time. The timelines will differ based on server policy, but servers should be looking to implement to the RFC. -- JG James Gould Fellow Engineer jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 7/14/20, 8:26 AM, "regext on behalf of Thomas Corte (TANGO support)" <regext-bounces@ietf.org on behalf of Thomas.Corte@knipp.de> wrote: Hello James, On 7/14/20 14:01, Gould, James wrote: > Thomas, > > The versions of the fee extension that you reference have similar language associated with returning avail="0" for premium domains: > > 1. fee-0.23 - https://secure-web.cisco.com/1kiROHoyjrP19LUExMku9rtxvisvx9NJMKw1wSLWwZCdjj5knAvCDts_hGetyd6bQENmggXNsIrgEHw8WCX68BU7IMZlk_v3dQ50AlcsDhXhknVr5eoFrR3JRBRH7won79Mya81Sr6LvWBgi540gAS1P-U_QN03xgFVCPXxui-KjDceHA2v6L7_PwOcyQAbFZJ4kCSbfGMGDWS1HXwY4I2dYYouKMPNXz_cV80CuvWtCojqr2pwqE5f6U2OcXAsqCC7_Fe09BvoSSo1LTXxdX4N2HvAKh_E8Krw7kx6OS_Ok/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-regext-epp-fees-08%23section-4 > 2. fee-0.21 - https://secure-web.cisco.com/1Uq5JtRLa--5dKWQkUzCW6Q7PFEND_NYkXdPQTy_B5riLnQjvMInA41XD73paaLCRdHAK9OpjFUqhe3YYrSGy88F5R3J0CPx-ua_WapjtFDLSYyQGDooO78aCWKW0Ue2hnZ-PidSxKjbxc-IbCUisaVa8b-Fm0HkJqJizP2QL7OBE-534awcgbpuoyCmsjnOGtMazHEzk7TxbMVtsQ5E4RTxUf_p7XBTM-MS4JRO5iLrPjb7Psqwk0SH1SOKWeDKVvVVLcCXSzhx3DAaqbtQ-2LbBOyxADfVnrcXpu-DkgQM/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-regext-epp-fees-05%23section-4 > > In both cases it reads: > > The server MUST return avail="0" in its response to a <check> command > for any domain name in the <check> command that does not include the > <fee:check> extension for which the server would likewise fail a > domain <create> command when no <fee> extension is provided for that > same domain name. Ok, thanks for pointing this out - looks as if we missed this addition when we upgraded our system from the older versions we had supported previously. > The very old fee-0.8 version specifies in https://secure-web.cisco.com/1QqHpNJJXZNFCGtsHrsi3YvVQeySWIrERGgDbIjZ0ryI7hw-1Qcjq5jUYfLMHJG3Gh0fC7SqgJgBa5LUPPZyv-Sd4yAIeV8d62sszDGnmFhlpNBN6J9DIO3zzeRg5CfjtWlcHycxaY8A7bXKM6_39O2cT8HmEtqOZu3IceTHwxF1ZsNFszUPXPxDlhkzOrhkp_4IO1s29UGdTVHTPGRHwWiDvYS9eIzB322EdVlwlsY8F884n8zVmlSjiOoBDdVme97R8f8cDEcsbJskDvyEeMYhyHElBOoiasNWIeaKXQq4/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-brown-epp-fees-05%23section-4 "Servers MUST provide clear documentation to clients about the circumstances in which this extension must be used.", which provides flexibility for the server to normalize the behavior as defined in draft-ietf-regext-epp-fees-05, draft-ietf-regext-epp-fees-08, and RFC 8748. Sure, it provides flexibility, but a registry must still be wary about the implications of any change in server behavior, even if the previous behavior resulted from a wrong implementation. We'll need to take this into consideration when altering the check results of our system where legacy versions of the extension are used. Our fee-1.0 implementation will for sure adhere to the language in the RFC. By the way, you're right that fee-0.8 is very old, however you'd be surprised that, for many registries, it is still the latest version they will support, with some only supporting even *older* versions (like fee-0.5 in the case of CentralNic). This has led to the unpleasant situation that some bigger registrars who want to avoid the effort of implementing newer versions even put pressure on registries to introduce support for these older versions, as they regard them as the established "de-facto" standard. Based on this experience, I'm afraid it will take a long time until fee-1.0 will be widely adopted by registries or registrars, if ever. Best regards, Thomas -- TANGO REGISTRY SERVICES® is a product of: Knipp Medien und Kommunikation GmbH Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: support@tango-rs.com Germany _______________________________________________ regext mailing list regext@ietf.org https://secure-web.cisco.com/12H21mMcVVt1O6ED0owoA5ZrlZgxkwD7P1zR1V5ILRhQa2o75D6pcV_MU3VBS218gvQIVqAn_rD_uEvMmceNyc5SsqZY_-146kpe3W8ySEu59RQhcFMM7Z1h_O7G-6qW7As34yQt1F53ubsNKeWnsfw3qNu-XixlsNmupMoofqnYqHyddj4Jr4g7V-r_kNoeLkghMvyjnynXxlWg21q6LD3mxpLsG_Lvl5UOTUGWOTHPfMR_QIV9iiJ-ydb-bHDD-NR_LwFZYFJy2bU6qWTKb8fH9LIc-ecVDbJDnYPNW0As/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
- [regext] RFC 8748 on Registry Fee Extension for t… rfc-editor
- [regext] RFC 8748, EPP Registry Fee Extension: av… Thomas Corte (TANGO support)
- Re: [regext] RFC 8748, EPP Registry Fee Extension… Gould, James
- Re: [regext] RFC 8748, EPP Registry Fee Extension… Thomas Corte (TANGO support)
- Re: [regext] RFC 8748, EPP Registry Fee Extension… Gould, James
- Re: [regext] RFC 8748, EPP Registry Fee Extension… Thomas Corte (TANGO support)
- Re: [regext] RFC 8748, EPP Registry Fee Extension… Gould, James
- Re: [regext] RFC 8748, EPP Registry Fee Extension… Jothan Frakes
- Re: [regext] RFC 8748, EPP Registry Fee Extension… Thomas Corte (TANGO support)
- Re: [regext] RFC 8748, EPP Registry Fee Extension… Thomas Corte (TANGO support)
- Re: [regext] RFC 8748, EPP Registry Fee Extension… Gould, James
- Re: [regext] RFC 8748, EPP Registry Fee Extension… Thomas Corte (TANGO support)
- Re: [regext] RFC 8748, EPP Registry Fee Extension… Gould, James
- Re: [regext] RFC 8748, EPP Registry Fee Extension… Thomas Corte (TANGO support)
- Re: [regext] RFC 8748, EPP Registry Fee Extension… Gould, James
- [regext] Re: RFC 8748, EPP Registry Fee Extension… Patrick Mevzek
- Re: [regext] EPP Registry Fee Extension: availabi… Thomas Corte (TANGO support)
- Re: [regext] EPP Registry Fee Extension: availabi… Patrick Mevzek