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
     *   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
     *   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
jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@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.wull...@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.wull...@sidn.nl<mailto:maarten.wull...@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 to regext-le...@ietf.org

Reply via email to