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

[Gavin Brown]

Hi George and Scott,



This WG, or whichever WG ends up doing this work (if any), should not be 
hesitant to take on work because of ICANN. The IETF should support a much wider 
audience than gTLD registries and registrars. This initiative has come from the 
ccTLD world, and it would be unfair to those operators to make their lives 
difficult "because ICANN".

G.

> On 25 Jul 2024, at 03:58, George Michaelson  wrote:
> 
> I think thats wise. Well said Scott.
> 
> I shouldn't put words in people's mouths but back in the CRISP days
> discussing whois replacement, I got a sense that the "whois problem"
> excised the ICANN board and seniors quite a lot. Maybe it was down to
> personalities, personal interests, but the idea of some consistency in
> data management was big.
> 
> I am less sure modern ICANN thinks like that. I don't understand the
> constituencies who make up "decision making" in this space. I would
> hope the contracts don't say literally "whois on port 43" but a more
> nuanced statement of public data which means RDAP can be grandfathered
> in instead of some "no not like that" outcome.
> 
> And in like sense if it said ".. its EPP specified over " then
> we might find ourselves in a difficult place if we said "its not EPP"
> but if we can say "EPP is now defined by ..." then we'd be on smoother
> grounds.
> 
> Or not. It's ICANN.
> 
> I fully expect (based on what I think I've read) that some people here
> say "its not EPP if it's not XML and SOAP" and maybe they're right.
> But the intent is to have extensible provisioning. If the fit now is
> for a HTTPS REST method, it's extensible, and it's for provisioning,
> I'm more of a mind to call it EPP-ng than "not EPP"
> 
> -G
> 
> ___
> regext mailing list -- regext@ietf.org
> To unsubscribe send an email to regext-le...@ietf.org

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

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

[Gould, James]

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

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: Orie Steele 
Date: Wednesday, July 24, 2024 at 9:00 PM
To: Maarten Wullink 
Cc: Registration Protocols Extensions 
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 
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

Best,

Maarten

___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

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

[Andrew Newton (andy)]

I agree with this. Furthermore, if a greenfield approach is desired it
would help if the protocol is not called EPP or a variation otherwise there
will be confusion.

-andy

On Thu, Jul 25, 2024 at 4:57 AM 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
>
>
> [image: cid87442*image001.png@01D960C5.C631DA40]
>
>
> *James Gould *Fellow Engineer
> jgo...@verisign.com
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com 
>
>
>
> *From: *Orie Steele 
> *Date: *Wednesday, July 24, 2024 at 9:00 PM
> *To: *Maarten Wullink 
> *Cc: *Registration Protocols Extensions 
> *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 
> 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
> 

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

[kowalik]

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
jgo...@verisign.com 



703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com 

*From: *Orie Steele 
*Date: *Wednesday, July 24, 2024 at 9:00 PM
*To: *Maarten Wullink 
*Cc: *Registration Protocols Extensions 
*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 
 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 disc

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

[Gould, James]

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
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: "kowa...@denic.de" 
Date: Thursday, July 25, 2024 at 10:26 AM
To: "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:


  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.

  1.  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

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

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

[kowa...@denic.de]

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
jgo...@verisign.com 



703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com 

*From: *"kowa...@denic.de" 
*Date: *Thursday, July 25, 2024 at 10:26 AM
*To: *"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:

 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
transition

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

[Gould, James]

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

[cid87442*image001.png@01D960C5.C631DA40]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: "kowa...@denic.de" 
Date: Thursday, July 25, 2024 at 11:10 AM
To: James Gould , "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:


  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

[cid:image002.png@01DADE85.6FC132C0]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: "kowa...@denic.de" 

Date: Thursday, July 25, 2024 at 10:26 AM
To: "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:


  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 
E

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

[kowa...@denic.de]

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


cid87442*image001.png@01D960C5.C631DA40

*James Gould
*Fellow Engineer
jgo...@verisign.com 



703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com 

*From: *"kowa...@denic.de" 
*Date: *Thursday, July 25, 2024 at 11:10 AM
*To: *James Gould , "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:

 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




*James Gould
*Fellow Engineer
jgo...@verisign.com


703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com



*From: *"kowa...@denic.de" 
 
*Date: *Thursday, July 25, 2024 at 10:26 AM
*To: *"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:

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

[Gould, James]

Pawel,

Great, let’s add the Hybrid Approach to the list of options for clarity:


  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.
  2.  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.
  3.  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

[cid87442*image001.png@01D960C5.C631DA40]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: "kowa...@denic.de" 
Date: Thursday, July 25, 2024 at 11:45 AM
To: James Gould , "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

[cid:image002.png@01DADE8A.5C1C42A0]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: "kowa...@denic.de" 

Date: Thursday, July 25, 2024 at 11:10 AM
To: James Gould 

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

[mario . loffredo=40iit . cnr . it]

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
jgo...@verisign.com [1]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com [6]

From: "kowa...@denic.de" 
Date: Thursday, July 25, 2024 at 11:45 AM
To: James Gould , "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 o

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

[Rubens Kuhl]

if possible and palatable, recharting RegExt still looks better to me. 

And this is orthogonal to the ICANN risk that has been mentioned, which can be 
addressed by not obsoleting or updating EPP RFCs, as they are the ones 
mentioned in the gTLD agreements. 



Rubens






> Em 24 de jul. de 2024, à(s) 21:59, Orie Steele  
> escreveu:
> 
> 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  > 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
>> 
>> Best,
>> 
>> Maarten
>> 
> ___
> regext mailing list -- regext@ietf.org
> To unsubscribe send an email to regext-le...@ietf.org



signature.asc
Description: Message signed with OpenPGP
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

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

[Arnt Gulbrandsen]

Hi,

I've attended the meetings since Prague but am not an EPP person. Permit me 
to offer a different perspective, based on what you've been saying about 
the other topics of discussion.


When you've talked about EPP during those meetings, you talked about the 
data model, the commands, but you hardly ever mentioned XML. XML didn't 
sound like a core part of the EPP that exists in your minds. I heard many 
arguments against or in favour of one proposal or another, but noone stood 
up and the mike to say "because … XML", see? XML seems about as central as 
TCP.


On this view, REPP might be called an unanticipated extension. If the data 
model and commands don't change at all, then this isn't the kind of 
extension that 5730-3 define, but it does extend that which you talk about 
as being EPP.


On the other hand, if the data model or commands do change… so I suggest 
that a separate WG makes sense if and only if REPP is permitted to change 
the data model or commands.


Arnt

___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

[regext] Re: [Technical Errata Reported] RFC9537 (8006)

[Jody Kolker]

Hello all,

I asked one of our developers at GoDaddy to implement the Redacted RFC with the 
changes that were included in the Errata.  He was able to implement the RFC 
with the proposed redaction as GoDaddy would be using it with redaction by 
empty value and redaction by replacement in under two hours.  He stated that 
GoDaddy's case is pretty simple and the RFC was straightforward to implement.

Has anyone else tried to implement the RFC with the additional Errata?

Thanks,
Jody Kolker
319-329-9805  (mobile)

Please contact my direct supervisor Scott Courtney (scourt...@godaddy.com) with 
any feedback.

This email message and any attachments hereto is intended for use only by the 
addressee(s) named herein and may contain confidential information. If you have 
received this email in error, please immediately notify the sender and 
permanently delete the original and any copy of this message and its 
attachments.

-Original Message-
From: RFC Errata System 
Sent: Thursday, June 27, 2024 5:26 AM
To: jgo...@verisign.com; dsm...@verisign.com; Jody Kolker 
; Roger Carney ; superu...@gmail.com; 
orie@transmute.industries; gal...@elistx.com; i...@antoin.nl
Cc: jgo...@verisign.com; regext@ietf.org; rfc-edi...@rfc-editor.org
Subject: [regext] [Technical Errata Reported] RFC9537 (8006)

Caution: This email is from an external sender. Please do not click links or 
open attachments unless you recognize the sender and know the content is safe. 
Forward suspicious emails to isitbad@.



The following errata report has been submitted for RFC9537, "Redacted Fields in 
the Registration Data Access Protocol (RDAP) Response".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid8006

--
Type: Technical
Reported by: James Gould 

Section: 4.2

Original Text
-
The "postPath" member MUST be set when the redacted field does exist in the 
redacted response for the Redaction by Empty Value Method (Section 3.2), the 
Redaction by Partial Value Method (Section 3.3), and the Redaction by 
Replacement Value Method (Section 3.4).

Corrected Text
--
The "postPath" member MAY be set when the redacted field does exist in the 
redacted response for the Redaction by Empty Value Method (Section 3.2), the 
Redaction by Partial Value Method (Section 3.3), and the Redaction by 
Replacement Value Method (Section 3.4).

Notes
-
The "postPath" member is an OPTIONAL member and this MUST can provide 
confusion.  The intent of this sentence was to outline which of the path 
members ("prePath", "postPath", and "replacementPath") to use when using path 
expressions and not to conflict with the OPTIONAL definition.  All of the path 
expression members are defined as OPTIONAL in the RFC, so this MUST needs be 
changed to a MAY to correct the confusion.

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it will be 
removed shortly by the RFC Production Center.) Please use "Reply All" to 
discuss whether it should be verified or rejected. When a decision is reached, 
the verifying party will log in to change the status and edit the report, if 
necessary.

--
RFC9537 (draft-ietf-regext-rdap-redacted-16)
--
Title   : Redacted Fields in the Registration Data Access Protocol 
(RDAP) Response
Publication Date: March 2024
Author(s)   : J. Gould, D. Smith, J. Kolker, R. Carney
Category: PROPOSED STANDARD
Source  : Registration Protocols Extensions
Stream  : IETF
Verifying Party : IESG

___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org