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

"Thomas Corte (TANGO support)" <Thomas.Corte@knipp.de> Thu, 25 June 2020 17:33 UTC

Return-Path: <Thomas.Corte@knipp.de>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id BFAB63A0E3C for <regext@ietfa.amsl.com>; Thu, 25 Jun 2020 10:33:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Dvawr0-b3a0c for <regext@ietfa.amsl.com>; Thu, 25 Jun 2020 10:32:56 -0700 (PDT)
Received: from kmx5a.knipp.de (kmx5a.knipp.de []) (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 598963A0E39 for <regext@ietf.org>; Thu, 25 Jun 2020 10:32:55 -0700 (PDT)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de []) by kmx5a.knipp.de (Postfix) with ESMTP id 49t6Y01c53z4vDL; Thu, 25 Jun 2020 19:32:51 +0200 (CEST)
Received: from dhcp203.intra.dtm.knipp.de (dhcp203.intra.dtm.knipp.de []) by hp9000.do.knipp.de (Postfix) with ESMTP id B83F47192A; Thu, 25 Jun 2020 19:32:51 +0200 (MESZ)
To: regext@ietf.org
References: <20200314164521.0B10EF406C9@rfc-editor.org>
From: "Thomas Corte (TANGO support)" <Thomas.Corte@knipp.de>
Organization: Knipp Medien und Kommunikation GmbH
Message-ID: <ac9d9567-e847-8802-14e4-07c36e216c19@knipp.de>
Date: Thu, 25 Jun 2020 19:32:53 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <20200314164521.0B10EF406C9@rfc-editor.org>
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: 49t6Y01c53z4vDL
X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:8391, ipnet:, country:DE]; LOCAL_WL_IP(0.00)[]
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/quXFM7l3oErLEHMRiENY637kHc8>
Subject: [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: Thu, 25 Jun 2020 17:33:01 -0000


we're currently working on implementing RFC 8748 (EPP Registry Fee
Extension) in our registry system, and I just stumbled upon this
paragraph in section 4 (Server Handling of Fee Information):

   "The server MUST return avail="0" in its response to a <check> command
   for any object in the <check> command that does not include the
   <fee:check> extension where the server would fail a domain <create>
   command when no <fee> extension is provided for that same object."

If my interpretation of this is correct, this means that the server is
supposed to reply avail="0" in a <domain:check> response for all
available domains which do not have a standard price, i.e. which require
the acceptance of special fees via the fee extension on <domain:create>,
unless the client supplies (any?) fee extension in with the
<domain:check> command.

I admit that I missed this part even in older versions of the draft, so I
may be late to the party.
Anyhow, I wonder:

* Is it a good idea to simply claim that a name is not available,
  even though it actually *is* available (if the client is ready to pay
  the special price)?

* Which kind of fee check extension is sufficient to report the name
  as "available"? What if the registrar merely checks for a renewal
  price, but not for a create price?
  Should he still get avail="1", even though he may still be oblivious to
  the higher registration price?

I understand that this is maybe another attempt to protect registrars
from offering / registering premium names inadvertently, but is it the
right way to do this?

Fee-unaware registrars may lose business by reporting names as taken,
even though they may be able to register them manually for their
customers (without EPP) after determining the price out-of-band.
And requiring the fee extension in the transform commands for
non-standard prices should be protection enough against inadvertent
premium registrations.

Also, it seems somewhat questionable to affect the outcome of the plain
availability check depending on the presence of the fee extension.


Best regards,


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