IETF Logo Mail Archive

Re: [regext] Re-chartering REGEXT?

kowalik@denic.de Tue, 16 April 2024 08:55 UTC

Return-Path: <kowalik@denic.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 E5FE6C14F68D for <regext@ietfa.amsl.com>; Tue, 16 Apr 2024 01:55:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denic.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNXM0V1XAc6h for <regext@ietfa.amsl.com>; Tue, 16 Apr 2024 01:55:39 -0700 (PDT)
Received: from mout-b-203.mailbox.org (mout-b-203.mailbox.org [195.10.208.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE7B1C14F60D for <regext@ietf.org>; Tue, 16 Apr 2024 01:54:50 -0700 (PDT)
Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-b-203.mailbox.org (Postfix) with ESMTPS id 4VJdCB0nhvz9tZG for <regext@ietf.org>; Tue, 16 Apr 2024 10:54:46 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denic.de; s=MBO0001; t=1713257686; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fM23Mczgpj6sv6izpVCJnzZ2o3qTRB4wXoyJ4uQK4NE=; b=aXVJAGFnrn+u50Zl0UTb1+iE9Z64DFAW4Y1JSi1NyBDvpf6gwH56GkUuq/b36N+CrIJv5T Oqz/6uus/wrXDKk0Nv7MnyQrLihVwxko6dF3/JVq237ltcJhhAjkNTt9RIRQDevRaN79un yes6MW6qAwNyL4t6TsNUlMPyqp0OgAKQ+BD2eqRWnYKNbsZ9ikGt+cofFWUiXF8HwNHoWW CjujuoTRi6damLCTrqdXKtH24z4DEMBMyoBO/Q1Tn6cpO3EIeN5Bs3hrd0xHS6kEx0wjEd 0ctE3hGx0HvE2LDquMMSJ8e+pogXNcEZuimIVDSkLNSfRhSesCkkv+ydFKM1eg==
Message-ID: <bee733cf-1cb4-4e92-95ba-ba2014108b5e@denic.de>
Date: Tue, 16 Apr 2024 10:54:44 +0200
MIME-Version: 1.0
From: kowalik@denic.de
To: regext@ietf.org
References: <50556621-BBB1-41D8-A167-96508F5FF0C6@sidn.nl> <CAAQiQRezKGVaSdqb9nRKhw3Jdd+0R=Tikhe0hQgsq8vMcGGTgQ@mail.gmail.com> <92D7BA88-CC1C-4A5E-9407-BCAE029FAFA3@verisign.com> <CAKr6gn1H2fDcwyWN4L-_hOQY9O2biBwD07udQ=VHpAg4F1J2mQ@mail.gmail.com> <f7044512-f07f-4d55-bc56-2410e341bfad@iit.cnr.it>
Content-Language: en-GB, de-DE
In-Reply-To: <f7044512-f07f-4d55-bc56-2410e341bfad@iit.cnr.it>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms000306030402040206020706"
X-MBO-RS-ID: a48d170d7098c214de4
X-MBO-RS-META: mot7c9sfg9zgyej5n5m5r4pnzxosqndm
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/AgERUhtAsBZSXUwaw8ENBEmP518>
Subject: Re: [regext] Re-chartering REGEXT?
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.39
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, 16 Apr 2024 08:55:44 -0000

Hi Mario,

On 16.04.24 09:39, Mario Loffredo wrote:
> However, let me just say that it appears a bit inconsistent to me that 
> we have almost finished to turn RDAP from stateless into stateful and 
> we are now planning to start a discussion about how to make EPP to go 
> opposite !?!

You mean the "session" variant of draft-ietf-regext-rdap-openid? I would 
not name it "turning RDAP into stateful". First there is a token variant 
which is same stateless as REPP can be, second it's an extension, which 
optionally extends the protocol not fundamentally changes it.

And one addition, as Maarten mentioned REPP does not have an intention 
to make changes to the base EPP, so even if REPP would be stateless it 
should not mean that we turn EPP to stateless by doing that.

Kind Regards,

Pawel

v2.23.0 | Report a Bug | By Email