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
jgo...@verisign.com [1]
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com [2]
From: "kowa...@denic.de" <kowa...@denic.de>
Date: Thursday, July 25, 2024 at 11:10 AM
To: James Gould <jgo...@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
jgo...@verisign.com [1]
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com [3]
From: "kowa...@denic.de" <kowa...@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
jgo...@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.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> 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-le...@ietf.org
