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

["[e-mail]" <[e-mail]>]

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:
>
>  1. Being stateless
>  2. Changing the command framework by not using the command XML for
>     many of the EPP commands.
>  3. Changing the response framework by not using the response XML for
>     some of the EPP responses
>  4. Changing the base XML schema and the XML URI, which will require
>     all of the EPP extensions to be updated
>  5. 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
>
>
> cid87442*image001.png@01D960C5.C631DA40
>
> *James Gould
> *Fellow Engineer
> [e-mail] 
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> *From: *"[e-mail]" <[e-mail]>
> *Date: *Thursday, July 25, 2024 at 10:26 AM
> *To: *"[e-mail]" <[e-mail]>
> *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:
>
>      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
>     [e-mail]
>     <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
>     703-948-3271
>     12061 Bluemont Way
>     Reston, VA 20190
>
>     Verisign.com
>     <http://secure-web.cisco.com/1S_6_mpoxAvgsWRR9qOU0lOtmJ-ZyI5FEmXyK2611IDuZJ5iXI7Ihjsyb1ti0d_buMVv0VFP5Cc-VFM9tY2MxAFo7QK7dn7iS_JlJe4kZrW05YdwSdx3xLq-e806_Gn3EoN_iM2hhdmrrctfHXPjqaDZznceKuUN__X-FvqUdvRHiKkuiriRd1UI61mHWUlFXRO3dffpdBssuN0ak1vfkngDQrcQqH8X2GNrv4cteigEKXORgFPTMindxXEImfi1LRv59iA1GSYuG1gK1VV8pBFggvNkm3L06rLkbLWyCv7g/http%3A%2F%2Fverisigninc.com%2F>
>
>     *From: *Orie Steele <[e-mail]>
>     <mailto:[e-mail]>
>     *Date: *Wednesday, July 24, 2024 at 9:00 PM
>     *To: *Maarten Wullink <[e-mail]>
>     <mailto:[e-mail]>
>     *Cc: *Registration Protocols Extensions <[e-mail]>
>     <mailto:[e-mail]>
>     *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
>     <[e-mail]> 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 [e-mail]
>
>     To unsubscribe send an email [e-mail]
>