[regext] Re: RESTful EPP Charter side meeting Thursday 13:00

mario.loffredo@iit.cnr.it Thu, 25 July 2024 16:46 UTC

Return-Path: <mario.loffredo@iit.cnr.it>
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 95B6DC15152D for <regext@ietfa.amsl.com>; Thu, 25 Jul 2024 09:46:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.006
X-Spam-Level:
X-Spam-Status: No, score=-2.006 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_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=iit.cnr.it
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 G2f2lTVucDrm for <regext@ietfa.amsl.com>; Thu, 25 Jul 2024 09:46:22 -0700 (PDT)
Received: from mx3.iit.cnr.it (mx5.iit.cnr.it [146.48.58.12]) (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 49661C1519B8 for <regext@ietf.org>; Thu, 25 Jul 2024 09:46:17 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 mx3.iit.cnr.it 76994C07C0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iit.cnr.it; s=mx520231221; t=1721925974; bh=NB7EQlUwHmyacmLT/S38ZBAItUCJXKP571zZluO5O3w=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=MTGuNrCZ61C69F25f26xgYJnAP/NsSPcwkcKl5Jf9+vziZ15Z42eBhOHrndP4anr/ MS7Sr1vfmcstzhg9t9RqiOL+Q8Wj10cG5/VhX13mAKQZvOlA4MKtTYpTFL9mB3GnPG UbhJ8ZCh30Os2ARKosl8TMionr24Cxp65ztqAlPr7MTH97D+PoI9t7MxSXTVaq8/QB 2o8oiWdoefu5fsahp4ONgFwpBqbOt8CGWYuqhQputot+a1V0SgZlNR3ezxB/6EOE34 QhAogyYEx2NbE2xgPfgp+vYb00V9IMIMRd57cy0noi4Q8irrtYlZ/p4y8fxrrf/ohd ym5w4EY0wJSnQ==
Received: from localhost (localhost [127.0.0.1]) by mx3.iit.cnr.it (Postfix) with ESMTP id 76994C07C0; Thu, 25 Jul 2024 18:46:14 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mx5.iit.cnr.it
Received: from mx3.iit.cnr.it ([127.0.0.1]) by localhost (mx5.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10028) with ESMTP id Tx_dQJ5IItTy; Thu, 25 Jul 2024 18:46:14 +0200 (CEST)
Received: from webmail.iit.cnr.it (mx1.iit.cnr.it [146.48.58.8]) by mx3.iit.cnr.it (Postfix) with ESMTPA id 34D55C0717; Thu, 25 Jul 2024 18:46:14 +0200 (CEST)
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Date: Thu, 25 Jul 2024 18:46:14 +0200
From: mario.loffredo@iit.cnr.it
To: "Gould, James" <jgould=40verisign.com@dmarc.ietf.org>
In-Reply-To: <99E21D50-65F4-4B8D-BBFC-2FF3D528B6E5@verisign.com>
References: <603C6F0D-CED2-4624-8F2E-6A9F4BEB6083@sidn.nl> <CAN8C-_KWKxJ47CkL31UNPCgs0wqi6zce=j4aFPvDY4e4cnXn7g@mail.gmail.com> <780DCB74-893A-4D32-8DAA-35BC91FD3AC7@verisign.com> <a5f9c82e-a050-4df2-ae48-135c1a5c17fb@denic.de> <C06E2B4E-36F0-4147-AB8E-0D4AB807B316@verisign.com> <3069766a-1c03-449c-ad93-e1f60675214e@denic.de> <74B6CCD2-0C04-42E6-B390-2255E19B77D6@verisign.com> <929b9944-0ab6-4475-a353-6984359a1799@denic.de> <99E21D50-65F4-4B8D-BBFC-2FF3D528B6E5@verisign.com>
Message-ID: <51fdc77af4cc3ee80906c2dba76db5da@iit.cnr.it>
X-Sender: mario.loffredo@iit.cnr.it
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: 2PTWGMO2YG57X7MLZBLJ4LNVHTT2OD2R
X-Message-ID-Hash: 2PTWGMO2YG57X7MLZBLJ4LNVHTT2OD2R
X-MailFrom: mario.loffredo@iit.cnr.it
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
CC: regext@ietf.org
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/oJeHZAjruO5uiSFL8_vuxpaMWa0>
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 folks,

I’m not yet operative so please forgive me if I will not reply to your 
messages suddenly.
Would just like to make you know my idea of “hybrid approach”.
I basically intend the REPP implementation as EoH whereas EPP 
Login/Logout are replaced by Bearer Token management.
That means updating the current REPP proposal by admitting one only URL 
and one only HTTP method i.e. POST.

Based on that, most of the EPP standard requests and responses would be 
preserved as well as the current EPP Extension mechanism. As a 
consequente, most of the implementation efforts made so far would still 
remain meaningful.

Please note that in that case a single server would be able to implement 
both EPP and REPP just as in RDAP the authentication can be accomplished 
through the session-based and the token-based OpenID implementation.

The REPP proposal wouldn’t be trivial anyway as it should describe how 
the Bearer Token is managed, I mean, how it is requested, got, refreshed 
and revoked.

Hope it could be helpful.


Best,
Mario (from India)

Il 2024-07-25 18:01 Gould, James ha scritto:
> Pawel,
> 
> Great, let’s add the Hybrid Approach to the list of options for
> clarity:
> 
> 	* Incremental Approach
> 
>  	* 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.
> 
> 	* Hybrid Approach
> 
>  	* Define a new provisioning protocol that will reuse key semantics
> of EPP.  The goal of reusing the key EPP semantics is to minimize the
> impact of transitioning the EPP services.  Further analysis is
> required to determine which key semantics of EPP to meet the goal,
> such as the ability to reuse the existing EPP extensions registered in
> the EPP Extension Registry.  This task will require focused analysis
> and requirements definition that may be handled via REGEXT
> re-chartering, or a new working group based on the level of EPP
> semantics that apply.
> 
> 	* Greenfield Approach
> 
>  	* 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.
> 
> Feel free to update the description of any of the approach options.
> 
> Thanks,
> 
> --
> 
> JG
> 
> James Gould
> Fellow Engineer
> jgould@Verisign.com [1]
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> Verisign.com [6]
> 
> From: "kowalik@denic.de" <kowalik@denic.de>
> Date: Thursday, July 25, 2024 at 11:45 AM
> To: James Gould <jgould@verisign.com>, "regext@ietf.org"
> <regext@ietf.org>
> Subject: [EXTERNAL] Re: [regext] Re: RESTful EPP Charter side meeting
> Thursday 13:00
> 
> Hi Jim,
> 
> Please refer to the slides Maarten presented yesterday. There is no
> assumption that REPP is EPP, at least not in a sense if EPP is defined
> as literally RFC 5730.
> 
> The Hybrid Approach as you call it is actually THE approach in my
> mind. And yes the Design Considerations require further work to be
> more specific and reflect what was discussed yesterday and what will
> be for sure further discussed in regext or in to-be-WG.
> 
> Kind Regards,
> 
> Pawel
> 
> On 25.07.24 08:26, Gould, James wrote:
> 
>> Pawel,
>> 
>> It relates since there is a question of the problem that is being
>> addressed.  If there is the assumption that REPP is EPP and not
>> defining a new provisioning protocol, then I don’t believe there
>> is alignment in defining the appropriate path forward.  Are you
>> proposing a third possible approach that could be called the Hybrid
>> Approach, which would define a new provisioning protocol that reuses
>> some of the important elements of EPP?  In the
>> draft-wullink-restful-epp Design Considerations, it includes
>> “Compatibility with existing EPP semantics defined in the EPP
>> RFCs”, that is associated with EPP compliance / reuse with no
>> specifics.  It would help to get more specifics related to what EPP
>> semantics are desired to be retained, since there are many that are
>> not retained.
>> 
>> --
>> 
>> JG
>> 
>> James Gould
>> Fellow Engineer
>> jgould@Verisign.com [1]
>> 
>> 703-948-3271
>> 12061 Bluemont Way
>> Reston, VA 20190
>> 
>> Verisign.com [2]
>> 
>> From: "kowalik@denic.de" <kowalik@denic.de>
>> Date: Thursday, July 25, 2024 at 11:10 AM
>> To: James Gould <jgould@verisign.com>, "regext@ietf.org"
>> <regext@ietf.org>
>> Subject: [EXTERNAL] Re: [regext] Re: RESTful EPP Charter side
>> meeting Thursday 13:00
>> 
>> Yes Jim, I am only not sure how this relates to what I've written.
>> 
>> Kind Regards,
>> 
>> Pawel
>> 
>> On 25.07.24 07:37, Gould, James wrote:
>> 
>> Pawel,
>> 
>> REPP is clearly not EPP and not an EPP extension (not a transport
>> compliant with RFC 5730 section 2.1, not any of the EPP extension
>> types defined in RFC 3735) .  Below is an example list of compliance
>> issues with REPP and EPP:
>> 
>> * Being stateless
>> * Changing the command framework by not using the command XML for
>> many of the EPP commands.
>> * Changing the response framework by not using the response XML for
>> some of the EPP responses
>> * Changing the base XML schema and the XML URI, which will require
>> all of the EPP extensions to be updated
>> * No clear mechanism to support extensions in many of the commands
>> and responses that don't use XML.  For example, how does the
>> Registry Fee extension work, which extends the check command and
>> check response?  If an EPP extension requires a change to work with
>> REPP, then REPP is not EPP.
>> 
>> We need to first come to agreement of what REPP is to produce a list
>> of reasonable requirements for the work.
>> 
>> Thanks,
>> 
>> --
>> 
>> JG
>> 
>> James Gould
>> Fellow Engineer
>> jgould@Verisign.com [1]
>> 
>> 703-948-3271
>> 12061 Bluemont Way
>> Reston, VA 20190
>> 
>> Verisign.com [3]
>> 
>> From: "kowalik@denic.de" <kowalik@denic.de>
>> Date: Thursday, July 25, 2024 at 10:26 AM
>> To: "regext@ietf.org" <regext@ietf.org>
>> Subject: [EXTERNAL] [regext] Re: RESTful EPP Charter side meeting
>> Thursday 13:00
>> 
>> 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:
>> 
>> * Incremental Approach
>> 
>> * 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.
>> 
>> * Greenfield Approach
>> 
>> * 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
>> 
>> James Gould
>> Fellow Engineer
>> jgould@Verisign.com [1]
>> 
>> 703-948-3271
>> 12061 Bluemont Way
>> Reston, VA 20190
>> 
>> Verisign.com [4]
>> 
>> 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 [5]
>> 
>> Best,
>> 
>> Maarten
>> 
>> _______________________________________________
>> 
>> regext mailing list -- regext@ietf.org
>> 
>> To unsubscribe send an email to regext-leave@ietf.org
> 
> 
> Links:
> ------
> [1] 
> applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com
> [2] 
> http://secure-web.cisco.com/19tEfAq7V73l-oq9Uddn11mb7lynLx349nIxf7WL8NlMhZRSJhFT8QQyYfFXTzRuBxvjjPmK3toMdtsoXAciBHTAsl4QsyoeiifeZotizpLSju6JfvI7mZkHae-pAIwpNgT8OddoAMlI7zXExHxPXf3Dd1sqdmV6w1GKK4Ncxb6G14yoRdQW6SnB8umhUe9zvLKHZm8KDa8wVs2v1zK2p51Ddbp6pVWmuSg_1-AsBlHUupnfS6NNOaHaZRwAF2wAH2l9_ftw4fZrs0_L_1FxgxN4qsrBIdd3_m7WaQnK7WjU/http%3A%2F%2Fverisigninc.com%2F
> [3] 
> http://secure-web.cisco.com/15ai9blPnsP69O30-agO9CGyD_a-wJxRFBC_VlguhRU99HCky28DfX7CdoDZ3xIq3ll-EIxkJ0t6sZfVtPYaqk4NynzqmexkAnVO0D11EphTBnlTLM27FoM97fVSvSnh1SGnvHH8JeoKhpUw1s9rcjkXKSysaNSCt-MzayghgcnhvQS4oq9Qee87hnhBlrEEM0KpWGhG_zpdxDkK-682qaYFKcTICx57D7MLZxAYPe_5aof-z85_IlIOmY47ldScKZAwFGatGtxPhXCU-05bY5jlraf3PAjkkP16LQ_XaRJY/http%3A%2F%2Fverisigninc.com%2F
> [4] 
> http://secure-web.cisco.com/1S_6_mpoxAvgsWRR9qOU0lOtmJ-ZyI5FEmXyK2611IDuZJ5iXI7Ihjsyb1ti0d_buMVv0VFP5Cc-VFM9tY2MxAFo7QK7dn7iS_JlJe4kZrW05YdwSdx3xLq-e806_Gn3EoN_iM2hhdmrrctfHXPjqaDZznceKuUN__X-FvqUdvRHiKkuiriRd1UI61mHWUlFXRO3dffpdBssuN0ak1vfkngDQrcQqH8X2GNrv4cteigEKXORgFPTMindxXEImfi1LRv59iA1GSYuG1gK1VV8pBFggvNkm3L06rLkbLWyCv7g/http%3A%2F%2Fverisigninc.com%2F
> [5] 
> https://secure-web.cisco.com/1c9F5WwSIlo9XMwTM6J8h11yl1EFLkyVrgN49FLlBoU5AK1JtkdZWOQXZeb_ahBS4P7-6NDCZenNLquQrX1DhBv4IwG5IEbq5QtL28jON0grvoikwD3NBrQxAECXWpMStlRhicpWcAxc4eg9ndNHhEfE_wyMX8jlZQo-p_CXPWo6t1qpA-hinWx2NVZOmFpeSbg8tCtMpTNMh2QityccUZPuxP32j8EKsUYzixCGwClZBjQsCRKz0zq5NAtVBuYCwBMOEFkv3cZLstbB0BCGyuGOOCQtM2NsKPFYGZyhyYVc/https%3A%2F%2Fwiki.ietf.org%2Fen%2Fmeeting%2F120%2Fsidemeetings
> [6] http://verisigninc.com/
> _______________________________________________
> regext mailing list -- regext@ietf.org
> To unsubscribe send an email to regext-leave@ietf.org