Re: [regext] EPP and rate-limiting

"Hollenbeck, Scott" <shollenbeck@verisign.com> Fri, 17 January 2020 14:43 UTC

Return-Path: <shollenbeck@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 35ADE120074 for <regext@ietfa.amsl.com>; Fri, 17 Jan 2020 06:43:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 Qtnm1NByI7pw for <regext@ietfa.amsl.com>; Fri, 17 Jan 2020 06:43:05 -0800 (PST)
Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (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 EABBC12002F for <regext@ietf.org>; Fri, 17 Jan 2020 06:43:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=679; q=dns/txt; s=VRSN; t=1579272185; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=z73fSYs2Rtv6H1plb6lzenY9T9eIZ3KkQEPTpe5GbEA=; b=NHKuen8QKD3Aodh714S5gwgMNjI1OrZhEOIvbzjN0HgNmRFzQtCTCfOa DwnZd4RwSsA12lgfwGUmXvsMfbUfDMYMRceKOsApH0vm780aTURWUnUnv /6lTG0tpzQFDZCNAeHMQLjKVjgX89LsJuPdMt+pXiOZD0mIHcMUrbzWlh pRiVpuHy5Iupc4YVkW00gBLpHaRJMWGup16WBnZa1O7Y9aHcMuFsH66+M dILTfO3q8KFhbodXI5S0ZN9etkSZHRj3lCcDBEdyWszqWJFW9UC7C/mLf Uk3Wpdy+yXQwpqkkOsxkO/ns/GhzkPcKiM9LQpEKD2WjWqhC6XdN28N0Y Q==;
IronPort-SDR: T45RPItPXaRRh8HALRrPYZvAmWw63oVeyNe7/h1vKCC7fKXsyg6Ueh2jUEid2GNNJdd6QXg/Oq 4m2QfM4iF1KxWVwGbnNY7gOguo+FGJp8xMb3/Wcg47ogbmwiy/egipE1GJoRZEi5NQPFk8rGtL 8jXmLJTLFqNYr7tTRTul0hNWHLht9G2f17MA4sGc0vyo902P7nd9J0ICkQA8dvj0rH7s0w7GfY eaaYj3HpeNLFeOdgHZx5ZwRZk7XqfhzDbAL6lM9PKL/u5XeaPg5bCEwvcxjMN0ZNe8qlB9OV67 oHA=
X-IronPort-AV: E=Sophos;i="5.70,330,1574121600"; d="scan'208";a="516602"
IronPort-PHdr: 9a23:ILTpyRdTa706uQp+Ja8XdZp/lGMj4u6mDksu8pMizoh2WeGdxcWzZh7h7PlgxGXEQZ/co6odzbaP7+a4Bidev97B6ClELMUXEUddyI0/pE8JOIa9E0r1LfrnPWQRPf9pcxtbxUy9KlVfA83kZlff8TWY5D8WHQjjZ0IufrymUoHdgN6q2O+s5pbdfxtHhCanYbN1MR66sRjdutMZjId/Jas90AfFr3lHd+lXxG5jOFafkwrh6suq85Nv7ipdt+g9+8JcVKnxYrg1Q6FfADk6KW4++dfltQPETQuB53scVnsZnx9VCAXb7x/0Q4n8vDLiuuVyxCeVM8v2TaspWTu59KdkVAXoiCYcODEn9mzcl9F9g7haoBKloBx/3pLUbYSIP/dwYq/RYdUXTndHU81MVSJOH5m8YpMPAeQfIOhYs4fzqVgArRS8BAmjGOzhxTBTi3/qxK060fgtHR3a0AA+Gd8FrXTarM/yNKcXSe25wqvGzTLHb/NSxzj97pPHfQ49rvGPRb57bNffxlUoFwPZklWcp5HuMjSO1uQNtGib6+5gWvypi2E8tQ5+vjuvy9wyiobXnIIVy0vE9SR2wIYzP9G3VEl7Ydu9HZZWqiqUNJN2T9s/T210oio2178LtJChcCQXyJkqyQTTZvOEfoSQ/x7vSPydLSp6iX55Yr6zmhm//Eu6xuHhVcS4yFhKoTRGn9XQs30A0h7e5dSbRvRn+0qtxCqA2BzW5+xEPE87i6TbJpslz7Eti5Ucr0LOFTLslkrslq+ZbEAk9/Ct6+Tgf7rpuIeRN5RxigHiKqQundG/AfggPggOQWeb/eO82aX+8EPlWLtGk/05nLHWvp/bOcgXu7S1AxFJ3YYk8Ra/Fy2q384FknUdMlJFYgmHj47zN17SJ/D4CO+zg1WqkDh12/DLJqDtDonXInTekrrsc6xx51NcxQc919xS6JFZBqkEIP3pW0/xsNLYDgU+Mwyx2+vnE9V91oQaWWKLHKCZNrjdvkGU6eIsOOSMepEauCz8K/g+5v7ugnk5lUUBcqmu2JsbcGq4Eeh+I0WFfXrshc8MHnwNvgokUOzriViCXiBTZnmsRaIx/Tc7CIO6AovZSICtmqSL3D2nEZ1OemBGFleMHG/yd4qaVPcDdi2TItN6nzwFS7ehV4Eh2QuptA/gxLo0ZtbTr2cSsoj/xt149uDJvRcz/np6FY7Vh2uKVX1mm24ZSiUe2qF050JnnBPLm7J1jPFICfRS6u9HFAAgOtSUm/Z3BN3iRirAc8uHDlG8TYP1Lys2S4d749gKZ0t7EdipjVSL5CGtH6Nf3+iQBJsw9q/a1XX6JO5jxmzHz6guiR8tRc4ZZj7uvbJ26wWGX92BqE6ejav/Lak=
X-IPAS-Result: A2HKAgD7xiFe/zCZrQplHAEBAQEBBwEBEQEEBAEBgXuDFYExCpUnmzcJAQEBAQEBAQEBBwEvAQGEQAKCLzgTAgMBAQsBAQEEAQEBAQEFAwEBAQKGLII7IoNWAQEBAQM6SwQCAQgRBAEBHxAyHQgCBAESCIMfriCCJ4VKhGqBNow2gUI+hCQ+ijcEr0wDB4I5ligjgjeYO45cmwUCBAIEBQIVgWmBe3CDPFAYDZZHdIwsgRABAQ
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Fri, 17 Jan 2020 09:43:02 -0500
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1779.002; Fri, 17 Jan 2020 09:43:02 -0500
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "bortzmeyer@nic.fr" <bortzmeyer@nic.fr>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] [regext] EPP and rate-limiting
Thread-Index: AQHVzUKvLCqpl1tHdEC8ZtwEsy3yZ6fu7K+w
Date: Fri, 17 Jan 2020 14:43:02 +0000
Message-ID: <c17a7b413e2349df9a72a8e934e92af9@verisign.com>
References: <20200117143018.GA20025@nic.fr>
In-Reply-To: <20200117143018.GA20025@nic.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/71XA6hSL-TRMPJS9sv1saivEoXE>
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 14:43:07 -0000

> -----Original Message-----
> From: regext <regext-bounces@ietf.org> On Behalf Of Stephane
> Bortzmeyer
> Sent: Friday, January 17, 2020 9:30 AM
> To: regext@ietf.org
> Subject: [EXTERNAL] [regext] EPP and rate-limiting
> 
> Sometimes, some clients are too talkative and, for instance, try <create> too
> often to grab a domain. I'm not sure of the best error code to return when
> such behaviour is detected. HTTP has 429 "Too Many Requests" (RFC 6585)
> but I don't find a proper code in EPP. Any idea?

Perhaps 2002 ("Command use error")?

S:    <result code="2002">
S:      <msg>Command use error; too many requests</msg>
S:    </result>

Scott