[regext] Re: RESTful EPP Charter side meeting Thursday 13:00
kowalik@denic.de Thu, 25 July 2024 14:24 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 669C2C1DFD4F for <regext@ietfa.amsl.com>; Thu, 25 Jul 2024 07:24:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.005
X-Spam-Level:
X-Spam-Status: No, score=-2.005 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 U-Z9fBvMHss5 for <regext@ietfa.amsl.com>; Thu, 25 Jul 2024 07:24:46 -0700 (PDT)
Received: from mout-b-206.mailbox.org (mout-b-206.mailbox.org [195.10.208.51]) (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 EAC03C1CAE9A for <regext@ietf.org>; Thu, 25 Jul 2024 07:24:44 -0700 (PDT)
Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:b231:465::2]) (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-206.mailbox.org (Postfix) with ESMTPS id 4WVCng2jgsz9tcM for <regext@ietf.org>; Thu, 25 Jul 2024 16:24:39 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denic.de; s=MBO0001; t=1721917479; 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=N047A0xcMtHPvKNdE2+xIDMON0FJpztAfI6h1i/NNrY=; b=NtE2ZacUSWEUl7ihVDePoH27ctu7Pm9TcnIP3rD8Stw3g76Bv6F/DNpicWGl7niDGLbI// W1/sO/eI7XU6e+F2ymq4KdHnButOwZ/fYw8WpTekL5UhDjc8gYHqn6dVr5zzRgkDuNsP3l Wbw+V6gsyL4ax+33XE3B3iIBaoE9HMImtxxxbkLK1lt5EYXzYW4dhCXMob/Ay7je2BTp7G p7LcTrgM+GdF04uA7JCS7YAA6X94oMjT0Ojim5t2ib7475bKBMUdyJGNm/cV7B2C9SRotM V5/1sI9DrKVhT2UZnC2lveFgYELzsh+he+5HHQmhg4USQZK/nEVvrGEyFWMVHw==
Message-ID: <a5f9c82e-a050-4df2-ae48-135c1a5c17fb@denic.de>
Date: Thu, 25 Jul 2024 07:24:36 -0700
MIME-Version: 1.0
From: kowalik@denic.de
To: regext@ietf.org
References: <603C6F0D-CED2-4624-8F2E-6A9F4BEB6083@sidn.nl> <CAN8C-_KWKxJ47CkL31UNPCgs0wqi6zce=j4aFPvDY4e4cnXn7g@mail.gmail.com> <780DCB74-893A-4D32-8DAA-35BC91FD3AC7@verisign.com>
Content-Language: en-GB, de-DE
In-Reply-To: <780DCB74-893A-4D32-8DAA-35BC91FD3AC7@verisign.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms000302010708060301050407"
X-MBO-RS-ID: b8c3f13100bbb265032
X-MBO-RS-META: 68iu54zqejq5jbte6w74my6kyuno3ia7
Message-ID-Hash: JGBG6WUGON4TJ5QXIQZ3QGSWD44U3AVO
X-Message-ID-Hash: JGBG6WUGON4TJ5QXIQZ3QGSWD44U3AVO
X-MailFrom: kowalik@denic.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-regext.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [regext] Re: RESTful EPP Charter side meeting Thursday 13:00
List-Id: Registration Protocols Extensions Working Group <regext.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/KTZ0HEN_epfUiRBOTV9sfVpcrCU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Owner: <mailto:regext-owner@ietf.org>
List-Post: <mailto:regext@ietf.org>
List-Subscribe: <mailto:regext-join@ietf.org>
List-Unsubscribe: <mailto:regext-leave@ietf.org>
Hi, I would not see it that black and white. Scott expressed perfectly yesterday, what I think should be a firm design goal for a RESTful approach, that data representations and protocol interactions should allow for easy and stateless translation layer from/to RFC5730 EPP. I would add that this should include also the extension framework supporting all current and potentially future extension without double standardisation effort needed for EPP and REPP. This is not greenfield approach, where such boundaries would not apply. This is also a bit broader than the definition of incremental approach. And it's an achievable goal. I know of at least 2 registries that actually have done it. EPP is not going anywhere so this is a reasonable approach to assume the implementers would take. Actually it is even expressed in Design Considerations section of draft-wullink-restful-epp already, just maybe not that straightforward and got lost in the discussion. Kind Regards, Pawel On 25.07.24 04:57, Gould, James wrote: > > I view two options for meeting the goals of REPP, which I believe is > to have a more Cloud-friendly provisioning protocol: > > 1. Incremental Approach > 1. Implement incremental changes to EPP that make it more > Cloud-friendly, which does need to be fully compliant with the > EPP RFCs. This includes adding support for the HTTP transport > that is handled by EoH, support for client-side state that can > be handled via an EPP command response extension (e.g., > leverage something like JWT, extend the login command and > login response to create the token, and have the extension > pass the token with each EPP command to propagate the state) > that can be used with any EPP transport (EoT, EoH, and EoQ), > and create an EPP URL routing layer that optimizes the routing > decisions to the EPP services. This is certainly not REST but > it would be fully compliant with the EPP RFCs and would not > require a rebuild of the existing EPP services, since the > extensions are optional. This work could be done by REGEXT, > where the only question mark is the definition of the EPP URL > routing layer in the existing charter. Other aspects of REPP > could be considered for the Incremental Approach, where this > list is what I’ve thought of thus far. > 2. Greenfield Approach > 1. Define a new provisioning protocol that does not attempt to > extend EPP, but instead takes the lessons learned from RDAP > for REST and the lessons learned from EPP for the data model > and extensibility to define a new RESTful provisioning > protocol. EPP is more than RFC 5730 but includes all the > extensions that have been created over the past 20 years, so > creating a new provisioning protocol that can support a > similar set of features will be a very large undertaking. > This large task is best suited for a new working group with a > defined set of requirements. Attempting to do this work in > REGEXT would need to de-prioritize the extension work, since > it will consume most if not all the focus. All the EPP > services and extensions would need to be re-implemented and > transitioned from EPP. I personally worked on the development > of EPP and the transition from RRP, and the effort and impact > should not be underestimated. > > What is currently defined in REPP is more Greenfield but is attempting > to maintain some compatibility with EPP. I would go with the fully > compatible Incremental Approach or a pure Greenfield Approach. > > -- > > JG > > > cid87442*image001.png@01D960C5.C631DA40 > > *James Gould > *Fellow Engineer > jgould@Verisign.com > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > *From: *Orie Steele <orie@transmute.industries> > *Date: *Wednesday, July 24, 2024 at 9:00 PM > *To: *Maarten Wullink <maarten.wullink@sidn.nl> > *Cc: *Registration Protocols Extensions <regext@ietf.org> > *Subject: *[EXTERNAL] [regext] Re: RESTful EPP Charter side meeting > Thursday 13:00 > > *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. > > Hi, > > I said that we heard 2 paths forward: > > - recharter / expand existing charter > > - new working group > > If you feel strongly about this topic, I welcome any comments on this > list or to me or the chairs privately. > > There seems to be energy to do this work, I'll work with you all to > find the right approach. > > Thanks to the authors and chairs for the presentation in today's meeting. > > Regards, > > OS, ART AD > > On Wed, Jul 24, 2024, 3:35 PM Maarten Wullink > <maarten.wullink@sidn.nl> wrote: > > Hi All, > > Thank you all, for the comments and suggestions during our > discussion earlier today about RESTful EPP. > > The Area Director suggested we create a new working group for this > and similar work. > > If you are interested in joining us, to discuss and write a > concept charter for this new WG, we have organised a side meeting > for this on Thursday. > > Online participation is also an option, the URL will be added to > the wiki shortly. > > Room: Tennyson > > Time: 1300-14:00 > > URL: https://wiki.ietf.org/en/meeting/120/sidemeetings > <https://secure-web.cisco.com/1c9F5WwSIlo9XMwTM6J8h11yl1EFLkyVrgN49FLlBoU5AK1JtkdZWOQXZeb_ahBS4P7-6NDCZenNLquQrX1DhBv4IwG5IEbq5QtL28jON0grvoikwD3NBrQxAECXWpMStlRhicpWcAxc4eg9ndNHhEfE_wyMX8jlZQo-p_CXPWo6t1qpA-hinWx2NVZOmFpeSbg8tCtMpTNMh2QityccUZPuxP32j8EKsUYzixCGwClZBjQsCRKz0zq5NAtVBuYCwBMOEFkv3cZLstbB0BCGyuGOOCQtM2NsKPFYGZyhyYVc/https%3A%2F%2Fwiki.ietf.org%2Fen%2Fmeeting%2F120%2Fsidemeetings> > > Best, > > Maarten > > > _______________________________________________ > regext mailing list --regext@ietf.org > To unsubscribe send an email toregext-leave@ietf.org
- [regext] RESTful EPP Charter side meeting Thursda… Maarten Wullink
- [regext] Re: RESTful EPP Charter side meeting Thu… Orie Steele
- [regext] Re: RESTful EPP Charter side meeting Thu… George Michaelson
- [regext] Re: RESTful EPP Charter side meeting Thu… Jim Reid
- [regext] Re: RESTful EPP Charter side meeting Thu… George Michaelson
- [regext] Re: RESTful EPP Charter side meeting Thu… Hollenbeck, Scott
- [regext] Re: RESTful EPP Charter side meeting Thu… George Michaelson
- [regext] Re: [Ext] Re: RESTful EPP Charter side m… Gavin Brown
- [regext] Re: RESTful EPP Charter side meeting Thu… Andrew Newton (andy)
- [regext] Re: RESTful EPP Charter side meeting Thu… kowalik@denic.de
- [regext] Re: RESTful EPP Charter side meeting Thu… kowalik
- [regext] Re: RESTful EPP Charter side meeting Thu… Gould, James
- [regext] Re: RESTful EPP Charter side meeting Thu… kowalik@denic.de
- [regext] Re: RESTful EPP Charter side meeting Thu… Rubens Kuhl
- [regext] Re: [Ext] Re: RESTful EPP Charter side m… Gavin Brown
- [regext] Re: RESTful EPP Charter side meeting Thu… Gould, James
- [regext] Re: RESTful EPP Charter side meeting Thu… mario.loffredo
- [regext] Re: RESTful EPP Charter side meeting Thu… Arnt Gulbrandsen
- [regext] Re: RESTful EPP Charter side meeting Thu… Maarten Wullink
- [regext] Re: [Ext] Re: RESTful EPP Charter side m… Maarten Wullink
- [regext] Re: RESTful EPP Charter side meeting Thu… Gould, James
- [regext] Re: RESTful EPP Charter side meeting Thu… Gould, James