[regext] EPP and cloud deployment, improvements possible?

2023-10-13 Thread Maarten Wullink
Hi All, Seeing that more and more registries are moving their infrastructure into the cloud, it might be a good time to take look again at the transport used for EPP. Adding a method for easily running EPP services in the cloud could make things easier for registries and registrars. some of the

Re: [regext] Call for agenda items IETF 118

2023-10-16 Thread Maarten Wullink
Hi Antoin, Maybe a bit late, but would it be possible to add a few minutes for a discussion about the usefulness of REST enabled EPP. Thanks! Maarten see below for my motivation from a mail to the list last week: Seeing that more and more registries are moving their infrastructure into the

Re: [regext] Call for agenda items IETF 118

2023-10-20 Thread Maarten Wullink
t;> to overrun. >> Perhaps we should consider a 2 hour meeting request for next IETF 119. >> >> Regards, >> >> Antoin >> >>> Op 16 okt. 2023, om 17:52 heeft Maarten Wullink >>> het volgende geschreven: >>> >>>

Re: [regext] Call for agenda items IETF 118

2023-10-23 Thread Maarten Wullink
> Ok, Maarten, I squeezed you in for the 10 minutes Andy gave up. Thank’s! > > You can upload your presentation to > https://datatracker.ietf.org/meeting/118/session/31683/propose_slides > Or you can send them to the chairs to do so when ready. > Please have your slides uploaded at latest 2023

Re: [regext] Call for agenda items IETF119

2024-01-28 Thread Maarten Wullink
Hi Antoin and Jim, I would like to request some time to present the progress made on the RESTful EPP draft and to get feedback on our work and open questions. thx. Maarten The draft can be found here: https://github.com/SIDN/ietf-epp-restful-transport and the draft for handling json, here: ht

[regext] RESTful EPP version 01

2024-02-15 Thread Maarten Wullink
Hi all, We have just uploaded the 01 version of the draft for RESTful EPP https://datatracker.ietf.org/doc/draft-wullink-restful-epp/ We have requested some time at the meeting in Brisbane, to discuss the changes we’ve made between the 00 and the 01 version and to receive guidance on how to be

Re: [regext] EPP Transport Service Discovery

2024-03-19 Thread Maarten Wullink
how about using an iana registry similar as described for rdap? see Bootstrap Service Registry for Domain Name Space iana.org

[regext] EPP evolution and the REGEXT charter

2024-03-21 Thread Maarten Wullink
Hi all, Is the charter for the REGEXT WG limited to working on EPP XML extensions only? If so, what is then required for allowing the different new transport proposals to continue? A new transport is clearly something different. Do we need to expand the current charter and maybe change the WG n

Re: [regext] EPP evolution and the REGEXT charter

2024-03-21 Thread Maarten Wullink
RFC5730 Section 2.7 describes how to extend the XML data model to create a new EPP extension. and the transport considerations in section 2.1 describe how to create a new transport mapping. The charter then considers both to be types of an EPP extension, this works for me. but it does seem ther

Re: [regext] EPP evolution and the REGEXT charter

2024-03-23 Thread Maarten Wullink
REPP is not meant to be a replacement for RFC5730. Version 01 uses a custom schema based on the RFC5730 schema, because that looked to be a cleaner way to do it. But we could change it so REPP uses the RFC5730 schema as in Version 00. In that case we can describe which XML elements and types ar

Re: [regext] EPP evolution and the REGEXT charter

2024-04-02 Thread Maarten Wullink
Hi James, > > An EPP transport mapping must fully comply RFC 5730 and specifically Section > 2.1 of RFC 5730. REPP defines application-level protocol aspects that do not > comply with RFC 5730, such as being stateless, When RFC5730 section 2.1 was written, an EPP deployment as a stateless s

[regext] Re-chartering REGEXT?

2024-04-11 Thread Maarten Wullink
Hello everyone, The REGEXT WG charter seems to be limited to only allow work on EPP extensions? The WG preliminary consensus is that updating the charter for new transports (requires RFC5730, sec 2.1 compliance) is not required. Because a new transport is regarded as a type of extension, so for

Re: [regext] Re-chartering REGEXT?

2024-04-15 Thread Maarten Wullink
Hi George and others, > > > The protocol is in the registry-registrar and client-registrar > interaction space we work on. Thank you George, that was just the point i was trying to make. For the re-charter discussion It does not really matter if we define something such as REPP to be a transp

Re: [regext] Re-chartering REGEXT?

2024-04-25 Thread Maarten Wullink
t;> D89FjLRT5lrZaVa9cMZxyPuSEYmYARHamAXBNMOFMXHHnujQGPhAF2M8id >>> 1FtuOAGKUZx_ >>>> 9lN0uy8-nt1j1GSUq_MDc4bXP3HycIzx_GA3O2pl8aT3qQv- >>> UMzd2TyyR6F9rxo3by0Gxd >>>> nKWY4K-F9kROR8T3Y8pcLSeN_xYzXCTdgqo- >>> ReR6LfvzIrlt1RqQuo4CdEXYRT7bpkT1Oz >>>>

Re: [regext] [Ext] Re-chartering REGEXT?

2024-04-25 Thread Maarten Wullink
Hi Gavin, Thank’s for your comments! If "scalability" (based on a cloud paradigm which is designed around HTTP) is the sole objective, then I think that draft-loffredo-regext-epp-over-http would be the "smallest shippable delta" to achieve that objective. However, your use of the term "REST",

[regext] Re: [Ext] New Version Notification for draft-brown-rdap-referrals-00.txt

2024-05-24 Thread Maarten Wullink
Hi Gavin, Like Marc, i’m not a big fan of duplicating the link information from the json response into the response headers. However, for the HEAD method request i do see a use case, because in this case there exists no data duplication and the client can efficiently navigate the Link headers

[regext] Re: regext - New Meeting Session Request for IETF 120

2024-06-03 Thread Maarten Wullink
We were thinking about requesting an additional side-meeting to discuss how to best proceed with RESTful EPP, because there is not much time during the regext meeting. But if there is an additional hour for regext, then this side-meeting may not be required. - Maarten > Op 3 jun 2024, om 16:5

[regext] Re: regext - New Meeting Session Request for IETF 120

2024-06-05 Thread Maarten Wullink
Hi Jim, We would like to discuss and make a decision on how to move forward with RESTful EPP, potential options to discus include: - Adopt under current charter - Adopt under updated charter (will send concept text to the list, before the meeting) - Create new working group - Work on it outside

[regext] Re: using experimental to move items forward

2024-06-18 Thread Maarten Wullink
Hi, +1 for optimizing the process where possible. But i wonder why this new process is limited to RDAP extensions only? What is the distinction between RDAP extensions and other work done in REGEXT such as EPP extensions? - Maarten > Op 17 jun 2024, om 16:25 heeft Hollenbeck, Scott > he

[regext] RESTful EPP draft next session how to move forward

2024-07-22 Thread Maarten Wullink
Hi All, During the next REGEXT session on Wednesday we will be asking the WG where to best continue to work on RESTful EPP (REPP). There was broad support for this work during previous sessions and on the mailing list and by other communities such as CENTR (centr.org ) But,

[regext] Re: RESTful EPP draft next session how to move forward

2024-07-23 Thread Maarten Wullink
Hi Scott, Sorry i forgot to include a reference to the draft, you can find it here. https://datatracker.ietf.org/doc/draft-wullink-restful-epp/ - Maarten Op 23 jul 2024, om 07:03 heeft Hollenbeck, Scott het volgende geschreven: -Original Message- From: Maarten Wullink Sent: Monday

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

2024-07-24 Thread Maarten Wullink
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 ha

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

2024-07-29 Thread Maarten Wullink
Hello, Based on the feedback and comments we received during the regext session and the side meeting, we have decided that the best way forward is to: Charter a new working group which will use the Hybrid approach as suggested by Jim Gould, and develop a new protocol, that will not be called EP