Re: [regext] EPP and rate-limiting
"Thomas Corte (TANGO support)" <Thomas.Corte@knipp.de> Fri, 17 January 2020 15:04 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 DF1B6120045 for <regext@ietfa.amsl.com>; Fri, 17 Jan 2020 07:04:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYzH7A2bMHDo for <regext@ietfa.amsl.com>; Fri, 17 Jan 2020 07:04:22 -0800 (PST)
Received: from kmx5b.knipp.de (kmx5b.knipp.de [IPv6:2a01:5b0:0:29::6a]) (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 4904E120074 for <regext@ietf.org>; Fri, 17 Jan 2020 07:04:22 -0800 (PST)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx5b.knipp.de (Postfix) with ESMTP id E8EFD3002AD for <regext@ietf.org>; Fri, 17 Jan 2020 15:04:20 +0000 (UTC)
Received: from flexo.fritz.box (fw.do.knipp.de [195.253.2.17]) by hp9000.do.knipp.de (Postfix) with ESMTP id C5DEC72387 for <regext@ietf.org>; Fri, 17 Jan 2020 16:04:20 +0100 (MEZ)
To: regext@ietf.org
References: <20200117143018.GA20025@nic.fr> <c17a7b413e2349df9a72a8e934e92af9@verisign.com> <20200117144941.GA22249@nic.fr>
From: "Thomas Corte (TANGO support)" <Thomas.Corte@knipp.de>
Organization: Knipp Medien und Kommunikation GmbH
Message-ID: <6378528d-677f-43dd-0153-832beab0ccb3@knipp.de>
Date: Fri, 17 Jan 2020 16:04:20 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <20200117144941.GA22249@nic.fr>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spamd-Bar: /
Authentication-Results: kmx5b.knipp.de; none
X-Rspamd-Server: s671
X-Rspamd-Queue-Id: E8EFD3002AD
X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:8391, ipnet:195.253.0.0/16, country:DE]; IP_WHITELIST(0.00)[195.253.2.54]
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/_5Ri1igaTXTJvdyYDLPqOvCizGs>
Subject: Re: [regext] EPP and rate-limiting
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: Fri, 17 Jan 2020 15:04:27 -0000
Hello, On 1/17/20 15:49, bortzmeyer@nic.fr wrote: > On Fri, Jan 17, 2020 at 02:43:02PM +0000, > Hollenbeck, Scott <shollenbeck@verisign.com> wrote > a message of 21 lines which said: > >> Perhaps 2002 ("Command use error")? > > May be but the text in RFC 5730 limits it to "the command cannot > be executed due to a sequencing or context error". Admittedly, looking at this, our 2502 doesn't seem to be overly suitable either: 2502 "Session limit exceeded; server closing connection" This response code MUST be returned when a server receives a <login> command and the command cannot be completed because the client has exceeded a system-defined limit on the number of sessions that the client can establish. It might be possible to establish a session by ending existing unused sessions and closing inactive connections. (as this clearly refers to the number of open registry connections only). I guess we interpreted "Session limit exceeded" in a liberal fashion, in the sense that exceeding a rate limit means exceeding a limit *of* this session, not the limit to the number of sessions. Anyway, as the goal is to stop the client from further hitting the server, closing the session (as opposed to let subsequent commands fail, allowing the load on the server to continue) is IMHO a good way to react, and in that case this seems to be the most suitable response code. 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
- [regext] EPP and rate-limiting Stephane Bortzmeyer
- Re: [regext] EPP and rate-limiting Thomas Corte (TANGO support)
- Re: [regext] EPP and rate-limiting Hollenbeck, Scott
- Re: [regext] EPP and rate-limiting bortzmeyer@nic.fr
- Re: [regext] EPP and rate-limiting Thomas Corte (TANGO support)
- Re: [regext] EPP and rate-limiting Gould, James
- Re: [regext] EPP and rate-limiting Patrick Mevzek
- Re: [regext] EPP and rate-limiting Francisco Obispo
- Re: [regext] EPP and rate-limiting InterNetX - Marco Schrieck