Re: [regext] EPP evolution and the REGEXT charter

"Andrew Newton (andy)" <andy@hxr.us> Fri, 22 March 2024 11:40 UTC

Return-Path: <andy@hxr.us>
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 898C3C1D4A8A for <regext@ietfa.amsl.com>; Fri, 22 Mar 2024 04:40:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.905
X-Spam-Level:
X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hxr-us.20230601.gappssmtp.com
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 y4r31j3Fjr7G for <regext@ietfa.amsl.com>; Fri, 22 Mar 2024 04:40:05 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 5F5C6C19ECBC for <regext@ietf.org>; Fri, 22 Mar 2024 04:40:05 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-513d23be0b6so2416064e87.0 for <regext@ietf.org>; Fri, 22 Mar 2024 04:40:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hxr-us.20230601.gappssmtp.com; s=20230601; t=1711107603; x=1711712403; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=010O7rw1l4oZBI4/6XIWYaPvMHjXQtOsh/QBWktyll4=; b=Cq5tfTyVet76BZWyuaBW4eBYuHSyAx+pDdpQWUwM+UaVxv8WBKlVrMk4l97Ix4J6kW EXwgz31kdjroUSKkwhHEUOy+S+7d4ruh9OnC2F+6ULTg5bxMJdi3KDgJHbBWw9qEHlf5 IEDTjAVVamztkmwLklA1Vut/4SE1MzjRwaZw9gAN+C5npSNzgmm4c0aP2Pv5+RO7TvSv zimti5LudpezEQBba69w9utOCBDypLT2QMk82qBeR77IEQsG5/kg0vaqbEGQoN3Tw991 B6LYwcu0PB/IWV3p2fjejpFQHhbPApCdyKMBXfmSN0FCGKpPt8JjBXIBatLvwilRqMoK Lmyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711107603; x=1711712403; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=010O7rw1l4oZBI4/6XIWYaPvMHjXQtOsh/QBWktyll4=; b=UthkMzNI4ZohRYo3ibqLK/+E/hAdHpa9ASHn2wyWg7kmeLdNVuAUdvcrzN7eOX/3rn cEkmYchzmAtYLrxfxWeeCKgjo9pYWIolO8Y4BBGRxbTKWEkec2b/fq12FLcPDy8BV3ZU oN0sitPXXsNYMiTxsLNjhRvOcmq76H1kZfxIpTDhqhRa0ZA3RhzrDza+HsZ388MENvun APXyrZi6CtPvKAB6qU/0r2Vol8tKBrfZnN1/sajAH0Q/ni5stfZnAB/57KFu4nfwZglS cG6O8g9V/a4pjO7tuzlep8EaHCthXqy++3pVnIGhdddFCWMzil/n2kl/4c+63ZQ9U9rV 7Gjw==
X-Forwarded-Encrypted: i=1; AJvYcCVGVNH/o3wE7KIrIPEhCwn/6Q+t0HUwrBmPX9dr3YUkfjz50zjOURpOoPqPzy1i0Q9+XYbBCIAFWm99C6HrkrA=
X-Gm-Message-State: AOJu0Yx/ZCtsIeUof4Ml4RkiWYg0Krph0coIgeSeLdyhsMgYX+IT1WBI 8vPDA3yiLsT/TiprMLDQUogOyy9b8r00q4KMMo5PRO5OkKNkPM6GUIxTafLoFiUmBxFXXB72ddE i/TgvUGOJf7dQt329KAy+PJrofUs3xBW4LpF8syw8ZTOs2WJs
X-Google-Smtp-Source: AGHT+IEPRBeKNJ5/U8Po5HK/TOXmE1ZrSj7H4QOD5HLpZsx/AlWO5+BEd5phi/Z6/rNf+59KQ4jsd4zswF2WiKSG5v4=
X-Received: by 2002:a19:ac01:0:b0:513:d4be:7e40 with SMTP id g1-20020a19ac01000000b00513d4be7e40mr1599903lfc.23.1711107603318; Fri, 22 Mar 2024 04:40:03 -0700 (PDT)
MIME-Version: 1.0
References: <8CA69CC0-D08D-420C-83C7-4A5B03D698B8@verisign.com> <a7b73d2bb3ec49b586230d8709424170@verisign.com> <LV3PR15MB6453A840D9C678809D94BB0EC9312@LV3PR15MB6453.namprd15.prod.outlook.com> <1f54547d-8fb1-4686-8a95-e9dcbe021d55@iit.cnr.it>
In-Reply-To: <1f54547d-8fb1-4686-8a95-e9dcbe021d55@iit.cnr.it>
From: "Andrew Newton (andy)" <andy@hxr.us>
Date: Fri, 22 Mar 2024 07:39:52 -0400
Message-ID: <CAAQiQReqVY91FF2_r=0KfWKUzc5Nt4nBRvzaZO5ZxjWp4Oux4g@mail.gmail.com>
To: Mario Loffredo <mario.loffredo=40iit.cnr.it@dmarc.ietf.org>
Cc: Jasdip Singh <jasdips@arin.net>, "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org>, "jgould=40verisign.com@dmarc.ietf.org" <jgould=40verisign.com@dmarc.ietf.org>, "maarten.wullink=40sidn.nl@dmarc.ietf.org" <maarten.wullink=40sidn.nl@dmarc.ietf.org>, "regext@ietf.org" <regext@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/1_eom6ONz-yeNkt12D2Y6FngPFA>
Subject: Re: [regext] EPP evolution and the REGEXT charter
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: Fri, 22 Mar 2024 11:40:09 -0000

I am against any logic that creates different gating factors for the
different, competing solutions. Any contortion of the concept of an
EPP "extension" that results in the favor of one set of drafts over
the other is obviously unfair.

-andy

On Fri, Mar 22, 2024 at 5:33 AM Mario Loffredo
<mario.loffredo=40iit.cnr.it@dmarc.ietf.org> wrote:
>
> Hi Jasdip,
>
>
> IMO, REPP is not an "EPP extension" as defined by RFC5730. It provides neither just a switch of transport (like EoH and EoQ) nor an extension to EPP comands and responses.
>
> Instead, it presents a full revision of EPP that maps some EPP features onto HTTP features.
>
> Moreover, the current proposal is incompatible with some existing or future documents including extensions to EPP query commands (see Jody's question at last meeting about REPP compatibility with the Fee Extension).
>
> On the contrary, in the spirit of achieving a full compliance with RFC5730, .it is going to update its EPP implementation that has been working since 2009.
>
>
> With regard to a possible RegExt rechartering, I also don't think we need it.
>
> RFC5730 already allows for implementing EPP over multiple transports. But it does even more, it makes some examples of possible alternatives to TCP.
>
> Therefore, leaving aside for the moment the debate about considering a new transport as an extension or not, it would be paradoxical if the protocol itself admitted other transports than TCP but it wouldn't be allowed to standardize them just like it has been done for TCP :-(
>
>
> Best,
>
> Mario
>
>
> Il 22/03/2024 01:12, Jasdip Singh ha scritto:
>
> Hi.
>
>
>
> Curious if the newly proposed “RESTful EPP” is considered a new protocol that is different from EPP, or is it an “extension” of EPP? (AFAICT, the former seems outside the current regext charter.)
>
>
>
> Thanks,
>
> Jasdip
>
>
>
> From: regext <regext-bounces@ietf.org> on behalf of Hollenbeck, Scott <shollenbeck=40verisign.com@dmarc.ietf.org>
> Date: Friday, March 22, 2024 at 9:56 AM
> To: jgould=40verisign.com@dmarc.ietf.org <jgould=40verisign.com@dmarc.ietf.org>, maarten.wullink=40sidn.nl@dmarc.ietf.org <maarten.wullink=40sidn.nl@dmarc.ietf.org>, regext@ietf.org <regext@ietf.org>
> Subject: Re: [regext] EPP evolution and the REGEXT charter
>
> From: regext <regext-bounces@ietf.org> On Behalf Of Gould, James
> Sent: Thursday, March 21, 2024 7:49 PM
> To: maarten.wullink=40sidn.nl@dmarc.ietf.org; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] EPP evolution and the REGEXT charter
>
>
>
> Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> Maarten,
>
>
>
> The charter refers to EPP extensions, which transports is a form of an EPP extension.  RFC 5730 defines the extension points for EPP and includes support for extending the transports based on Section 2.1 “Transport Mapping Considerations”.  I don’t believe that there is a need to revise the REGEXT charter to support the additional of new EPP transports.
>
> [SAH] Agreed. New transport mappings are just another type of extension as long as they preserve the data model described in RFC 5730.
>
>
>
> Scott
>
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
>
> --
> Dott. Mario Loffredo
> Senior Technologist
> Technological Unit “Digital Innovation”
> Institute of Informatics and Telematics (IIT)
> National Research Council (CNR)
> via G. Moruzzi 1, I-56124 PISA, Italy
> Phone: +39.0503153497
> Web: http://www.iit.cnr.it/mario.loffredo
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext