Re: [regext] EPP evolution and the REGEXT charter

Pawel Kowalik <kowalik@denic.de> Fri, 22 March 2024 09:01 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 F0827C180B58 for <regext@ietfa.amsl.com>; Fri, 22 Mar 2024 02:01:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=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 YngxQaGijElG for <regext@ietfa.amsl.com>; Fri, 22 Mar 2024 02:01:49 -0700 (PDT)
Received: from mout-b-112.mailbox.org (mout-b-112.mailbox.org [IPv6:2001:67c:2050:102:465::112]) (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 551A1C180B78 for <regext@ietf.org>; Fri, 22 Mar 2024 02:01:43 -0700 (PDT)
Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::102]) (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-112.mailbox.org (Postfix) with ESMTPS id 4V1GXf27qczDtQZ; Fri, 22 Mar 2024 10:01:38 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denic.de; s=MBO0001; t=1711098098; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=J4yP2keFnxwZU+mQzB6jwyQA6Dsxa/o1Qw+lSBeFIBY=; b=S1UpQlCBHYAdMcFx7L6hNLDs6v9fJwzDPTJlPRu0iAQ3njVWc/fu+l7HQ7bFHXBlgeO9h2 Ko5IZ4ZTw+eIfi4yq2RRd3OLSS4jOjR98CP3tRn+BbDLHkyPjBvyIRJGfdrAuAKFssay1a EIVhdDosofXHnjb/LJrnYbzGJ1+4xfHYk1HG1d+6+qBlVkC1Mnd7vKnz4QPOzQWo1/7q4r 3yuT7+6lMFRu+uqt1IYX0xT+BVqQP2ov+XVQre0VBwlgKjebck3x0SHPeRmj2jJDF/CWEg FFPdadsMuh2sb4LGAkXhYZqKBYYEIh/VsamyWvGWYHQAT3ED78a10QDe32zfCQ==
X-Header: Open-Xchange USM Mailer (USM Version: 7.10.6-5, EAS Version: 7.10.6-8, Build 14f76313354ce6e183b752fd1ffa53d1f0cd7e43)
Content-Type: multipart/alternative; boundary="Apple-Mail-CE259088-C1F1-478B-8E68-30A98C5ED63A"
Content-Transfer-Encoding: 7bit
From: Pawel Kowalik <kowalik@denic.de>
Mime-Version: 1.0
Date: Fri, 22 Mar 2024 10:01:26 +0100
Message-ID: <1321070038.2919.1711098097136@localhost>
References: <8EF3FDBF-812B-43AB-A3B3-A907C0CBDF52@sidn.nl>
Cc: "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org>, jgould@verisign.com
In-Reply-To: <8EF3FDBF-812B-43AB-A3B3-A907C0CBDF52@sidn.nl>
To: Maarten Wullink <maarten.wullink=40sidn.nl@dmarc.ietf.org>, regext@ietf.org
X-MBO-RS-ID: 462fd2c7ccfd81ed527
X-MBO-RS-META: pcru668ucrwtzjdmf4mrhtrzh8uqcruw
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/0lWHMEyIdquValK21XXcd2t81Eo>
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 09:01:52 -0000

Hi,

<rant>
After the discussion we had in Prague my impression was that the group was open to consider approaches that go beyond just exchanging the transport.
And as Maarten already highlighted in Prague there is an immersing need to have provisioning protocol in form of REST API with JSON representation, which is now being addressed with not compatible singular solutions already which call for standardisation effort at least to start. The group gave a guidance how to proceed which was followed and now the charter card starts to be played… kind of inconsistent.
If the charter poses an issue to proceed let’s discuss what is the best way to address it. I am still of an opinion that this WG is the best group of people with the right expertise to move this topic forward.
</rant>

Kind regards
Pawel Kowalik 

> Am 22.03.2024 um 01:18 schrieb Maarten Wullink <maarten.wullink=40sidn.nl@dmarc.ietf.org>:
> 
> 
> RFC5730 Section 2.7 describes how to extend the XML data model to create a new EPP extension. 
> and the transport considerations in section 2.1 describe how to create a new transport mapping. 
> 
> The charter then considers both to be types of an EPP extension, this works for me. 
> but it does seem there is some ambiguity there.  
> 
> Maarten
> 
>> 
>> 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