Jim, Scott, There exists a lot of confusion about REPP, here is my attempt to try to answer some of these question.
Q) What is the goal of REPP? A) The goal is to create a "RESTful API for EPP" to increase scalability of an EPP service, make it easier to integrate into registry/registrar systems through the use of modern HTTP/REST based APIs and also include support for other data formats such as JSON. Maybe, a good analogy would be that REPP would be to EPP, what RDAP is to WHOIS? Q) Is REPP a stateless version of EPP? A) No, REPP can be designed to be stateful to conform to the requirement (RFC5730 section 2.1) that a transport MUST preserve the stateful nature of the EPP protocol. When using REPP, EPP is layered over HTTTP and REST, which are both stateless, but the EPP protocol itself can be kept stateful. This is similar to the draft proposal for EPP over HTTP and Quic. After the login request, the client would receive a session identifier/token to couple the server state to the client. Q) Do we need to change the existing EPP RFCs? A) No, for REPP we would not need to change any of the existing EPP RFCs. Q) Are the existing EPP extensions compatible with REPP? A) Yes, all existing EPP extensions should work fine, we have have not worked out all the details but we do feel that this is not an issue. -- Maarten > Op 24 apr 2024, om 20:38 heeft James Galvin <gal...@elistx.com> het volgende > geschreven: > > [You don't often get email from gal...@elistx.com. Learn why this is > important at https://aka.ms/LearnAboutSenderIdentification ] > > Speaking as a co-Chair and without having coordinated with my co-chair, I > want to say two things. > > First, Scott’s question here is critical in my opinion. It could also be > stated as, “What problem are we trying to solve”? I don’t feel like I’ve > seen consensus on the answer to that question. Certainly a few different > ideas have been suggested, some even reasonably aligned. However, a > “stateless EPP” versus the “stateful EPP” are fundamentally different things > in my opinion, and I hope many of you. We need actual text that answers that > question before we can consider the question of whether or not the work fits > within the remit of our current charter. > > Second, broadly speaking, I have always considered our charter as covering > most things within the scope of the EPP and RDAP base documents as we have > them today. For me, anything that suggests changing the fundamentals of > anything in those documents is not within our charter. I’m certainly not > opposed to new work on something similar to but not the same as our base EPP > and RDAP. However, personally, the greater the dissimilarity of the work to > our base EPP and RDAP, the less inclined I would be to rechartering this > group to address the new work. Personally, I would want to advocate for a > new working group. > > Having said all that, what we do and don’t do is up to the consensus of the > group and our Area Director. > > Let’s have the discussion here. I would ask that to continue the discussion > it would be best if the WG could have some text to consider. If anyone wants > to submit some text or a draft document with a proposal, then we can see > where a discussion of that takes us. > > Thanks, > > Jim > REGEXT co-Chair > > > On 16 Apr 2024, at 11:02, Hollenbeck, Scott wrote: > >> I think there's a basic question to be answered first: what's the goal? >> >> If the answer is "a RESTful API for EPP", it might be possible to do that >> within the confines of the existing charter if it can be done without >> changing any of the existing core EPP RFCs. There's an old axiom about the >> IETF not standardizing APIs, but we've already done RDAP. Maybe this is >> similar. >> >> If the answer is "specify a web service that's EPP-ish", I agree that >> rechartering is probably necessary. >> >> Scott >> >>> -----Original Message----- >>> From: regext <regext-boun...@ietf.org> On Behalf Of George Michaelson >>> Sent: Monday, April 15, 2024 7:15 PM >>> To: regext@ietf.org >>> Subject: [EXTERNAL] Re: [regext] Re-chartering REGEXT? >>> >>> 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. >>> >>> I don't think the new protocol is just a new transport *LAYER* but I also do >>> support re-charter to include consideration of this protocol suite. >>> >>> My reasoning is that we're the people who are going to wind up having to >>> talk >>> about it. Of course it's irritating from a perspective of RDAP and EPP >>> proponents to see more work jammed into this WG and I actually generally >>> dislike charter extension, but the context is clear: >>> >>> The protocol is in the registry-registrar and client-registrar interaction >>> space we >>> work on. >>> >>> G >>> >>> On Tue, Apr 16, 2024 at 3:37 AM Gould, James >>> <jgould=40verisign....@dmarc.ietf.org> wrote: >>>> >>>> Andy, >>>> >>>> REPP is not a transport, but a new provisioning protocol that is not >>> supported in the existing charter. If you believe REPP is a transport, >>> please >>> describe how it complies with section 2.1 of RFC 5730. >>>> >>>> Thanks, >>>> >>>> -- >>>> >>>> JG >>>> >>>> >>>> >>>> James Gould >>>> Fellow Engineer >>>> jgo...@verisign.com >>>> <applewebdata://13890C55-AAE8-4BF3-A6CE- >>> B4BA42740803/jgould@Verisign.c >>>> om> >>>> >>>> 703-948-3271 >>>> 12061 Bluemont Way >>>> Reston, VA 20190 >>>> >>>> Verisign.com >>>> <http://secure- >>> web.cisco.com/10VTAY9gOxn3SyGCbx0Iw10mjg42vKiJd9gTlNVhf >>>> 28244PWyM4jb2c-ibruKGejaYoPvmqmnSM9Z2eNTlzxMBoW7sZ23A5- >>> 6ZDa51f4CX1aG2k >>>> >>> D89FjLRT5lrZaVa9cMZxyPuSEYmYARHamAXBNMOFMXHHnujQGPhAF2M8id >>> 1FtuOAGKUZx_ >>>> 9lN0uy8-nt1j1GSUq_MDc4bXP3HycIzx_GA3O2pl8aT3qQv- >>> UMzd2TyyR6F9rxo3by0Gxd >>>> nKWY4K-F9kROR8T3Y8pcLSeN_xYzXCTdgqo- >>> ReR6LfvzIrlt1RqQuo4CdEXYRT7bpkT1Oz >>>> /http%3A%2F%2Fverisigninc.com%2F> >>>> >>>> >>>> >>>> >>>> On 4/15/24, 1:20 PM, "regext on behalf of Andrew Newton (andy)" >>> <regext-boun...@ietf.org <mailto:regext-boun...@ietf.org> on behalf of >>> a...@hxr.us <mailto:a...@hxr.us>> wrote: >>>> >>>> >>>> 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. >>>> >>>> >>>> Maarten, >>>> >>>> >>>> I think proposing some charter text is a good idea. >>>> >>>> >>>> And I support this if the charter is to be used to exclude some >>>> proposals for EPP transports but not others, as has been argued. >>>> >>>> >>>> -andy >>>> >>>> >>>> On Thu, Apr 11, 2024 at 11:59 PM Maarten Wullink >>>> <maarten.wullink=40sidn...@dmarc.ietf.org >>> <mailto:40sidn...@dmarc.ietf.org>> wrote: >>>>> >>>>> 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 >>>>> anything >>> else we would need to update the charter? >>>>> >>>>> This means there is no defined process anywhere, currently, for EPP >>>>> related work, such as RESTful EPP (or anything else that is not a >>>>> extension), >>> which according to some in this WG is not a transport but something else. >>>>> >>>>> RESTful EPP does not require modification of the EPP RFCs, it does include >>> support for alternative data representations such as JSON. >>>>> >>>>> The participants of this WG are the experts in this area, and the right >>>>> people >>> to also work on improvements and/or enhancements of the EPP protocol and >>> new work such as RESTful EPP. >>>>> >>>>> Therefore, I propose that we expand the charter of this WG to also include >>> the above-mentioned activities e.g. not strictly limiting the WG to >>> extensions >>> only. >>>>> >>>>> I’m willing to help in updating the charter if this something we agree on >>> doing. >>>>> >>>>> Best, >>>>> >>>>> Maarten >>>>> >>>>> ------ >>>>> ps: >>>>> >>>>> The previous version of the charter included text, that did allow work on >>> more than extensions only: >>>>> >>>>> “The working group may also, in consultation with its responsible >>>>> area director, take on work related to the operation of Internet >>>>> identifier registries, beyond the EPP and RDAP protocols.” >>>>> >>>>> See: >>>>> https://secure- >>> web.cisco.com/1pZ9xY4B2hhezD1LASpYU9C9QLU_I8ijwDhrAON >>>>> iX2WujSy1_vkXH6R3dC- >>> XOs3hs8GhnjSqn4hoIrURMcauciMp2aW9yObvXrtcQfNn5y3 >>>>> >>> 9QAI_y_nrDueqrchdGrckElb2y8uY6jnSOVocfgGUy3JGWGYYRDY4eaaVGYW4p >>> 0HCiWX >>>>> l_U-V5l_hWGXcSEavgzX-crhYmdNvhH- >>> u2THur7He9dDY47ixzEm4kaOgHenXF4Mjj6X >>>>> >>> w63FB7TA6StLsEn1cH4ZzXrkRso6sqhMOPIxW0M12SiAp3Az1rqdgYd_E/http >>> s%3A%2 >>>>> F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-regext%2F01-00%2F >>>>> <https://secure- >>> web.cisco.com/1pZ9xY4B2hhezD1LASpYU9C9QLU_I8ijwDhrAO >>>>> NiX2WujSy1_vkXH6R3dC- >>> XOs3hs8GhnjSqn4hoIrURMcauciMp2aW9yObvXrtcQfNn5y >>>>> >>> 39QAI_y_nrDueqrchdGrckElb2y8uY6jnSOVocfgGUy3JGWGYYRDY4eaaVGYW4 >>> p0HCiW >>>>> Xl_U-V5l_hWGXcSEavgzX-crhYmdNvhH- >>> u2THur7He9dDY47ixzEm4kaOgHenXF4Mjj6 >>>>> >>> Xw63FB7TA6StLsEn1cH4ZzXrkRso6sqhMOPIxW0M12SiAp3Az1rqdgYd_E/htt >>> ps%3A% >>>>> 2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-regext%2F01-00%2F> >>>>> >>>>> This was modified for the current charter, but still not very specific >>>>> and may >>> allow for work on RESTful EPP? >>>>> >>>>> "The working group may also take on work to develop specifications >>>>> that describe the following types of information exchanged between >>>>> entities involved in Internet identifier registration that are using >>>>> the RDAP or EPP protocols: >>>>> • Uniform representation formats for publishing local policy or >>>>> configuration options regarding EPP and RDAP use. >>>>> • Data formats for files exchanged between registration entities >>>>> that need insertion in or extraction from EPP or RDAP. >>>>> • Technical guidance for registration processes that are supported >>>>> by EPP or RDAP.” >>>>> >>>>> >>>>> _______________________________________________ >>>>> regext mailing list >>>>> regext@ietf.org <mailto:regext@ietf.org> >>>>> https://secure- >>> web.cisco.com/1KvgG0690znrXWuB3hdtOx8bFSBFJMVkNZ5g8zP >>>>> >>> MeStofdEIwM5iRQBNJUcSsE6gROXlW9ce2rNNyP9JIFNMdD3qAJa8xrA2wKLF >>> akvQ61D >>>>> >>> RHxQLVjdwPbxzo5BV1itYp75wcGjQk4CwDA0lQI54wUygUhug3rcMp5yeQb9 >>> _PLgXgM8 >>>>> eklr87_hvlNWXU_-41hgJWbb4kMACk- >>> BRDzKtZHXPAUm6b27OZrVUNee4FpEbr5z2Zmh >>>>> GFmjGtaGbOFxjlmkUq5FUncipetsTP1KpPA- >>> g33rNu37yQBieczmC5kkY/https%3A%2 >>>>> F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext >>>>> <https://secure- >>> web.cisco.com/1KvgG0690znrXWuB3hdtOx8bFSBFJMVkNZ5g8z >>>>> >>> PMeStofdEIwM5iRQBNJUcSsE6gROXlW9ce2rNNyP9JIFNMdD3qAJa8xrA2wKL >>> FakvQ61 >>>>> >>> DRHxQLVjdwPbxzo5BV1itYp75wcGjQk4CwDA0lQI54wUygUhug3rcMp5yeQb >>> 9_PLgXgM >>>>> 8eklr87_hvlNWXU_-41hgJWbb4kMACk- >>> BRDzKtZHXPAUm6b27OZrVUNee4FpEbr5z2Zm >>>>> hGFmjGtaGbOFxjlmkUq5FUncipetsTP1KpPA- >>> g33rNu37yQBieczmC5kkY/https%3A% >>>>> 2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> >>>> >>>> >>>> _______________________________________________ >>>> regext mailing list >>>> regext@ietf.org <mailto:regext@ietf.org> >>>> https://secure- >>> web.cisco.com/1KvgG0690znrXWuB3hdtOx8bFSBFJMVkNZ5g8zPMe >>>> >>> StofdEIwM5iRQBNJUcSsE6gROXlW9ce2rNNyP9JIFNMdD3qAJa8xrA2wKLFakv >>> Q61DRHxQ >>>> >>> LVjdwPbxzo5BV1itYp75wcGjQk4CwDA0lQI54wUygUhug3rcMp5yeQb9_PLgX >>> gM8eklr87 >>>> _hvlNWXU_-41hgJWbb4kMACk- >>> BRDzKtZHXPAUm6b27OZrVUNee4FpEbr5z2ZmhGFmjGtaG >>>> bOFxjlmkUq5FUncipetsTP1KpPA- >>> g33rNu37yQBieczmC5kkY/https%3A%2F%2Fwww.ie >>>> tf.org%2Fmailman%2Flistinfo%2Fregext >>>> <https://secure- >>> web.cisco.com/1KvgG0690znrXWuB3hdtOx8bFSBFJMVkNZ5g8zPM >>>> >>> eStofdEIwM5iRQBNJUcSsE6gROXlW9ce2rNNyP9JIFNMdD3qAJa8xrA2wKLFak >>> vQ61DRHx >>>> >>> QLVjdwPbxzo5BV1itYp75wcGjQk4CwDA0lQI54wUygUhug3rcMp5yeQb9_PL >>> gXgM8eklr8 >>>> 7_hvlNWXU_-41hgJWbb4kMACk- >>> BRDzKtZHXPAUm6b27OZrVUNee4FpEbr5z2ZmhGFmjGta >>>> GbOFxjlmkUq5FUncipetsTP1KpPA- >>> g33rNu37yQBieczmC5kkY/https%3A%2F%2Fwww.i >>>> etf.org%2Fmailman%2Flistinfo%2Fregext> >>>> >>>> >>>> >>>> _______________________________________________ >>>> regext mailing list >>>> regext@ietf.org >>>> https://secure-web.cisco.com/1D0Tq_GXiIN4Z2FKElYhxl8f- >>> orxRNy6qSMpHUfKK >>>> >>> QBDULJas_XL2jaCJh8sPN4Jnvglu7_qVHK9tDK4m13QKgWqw1TfhejL4tbxhT2 >>> KaR9hdAl >>>> >>> SZK8SzRYpUJxz6e1HUj7wQqKB6Ddsk9YvBLj3ZYRpL1aooJCUOv5WRxnxbRdlG >>> R568g1hO >>>> 0GxFPH7gdfT-wVTrpiLbgcA80j163vTPg6XScic7apv2- >>> uxH6PmiHhniI0S7HOBWggvyDd >>>> >>> ymhHEyIKjl0VBrj241hwWtsGVrrgux981psezLUf6xTDpDZxkvwNdxyrHfZN1kg >>> CA_WARX >>>> /https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext >>> >>> _______________________________________________ >>> regext mailing list >>> regext@ietf.org >>> https://secure-web.cisco.com/1D0Tq_GXiIN4Z2FKElYhxl8f- >>> orxRNy6qSMpHUfKKQBDULJas_XL2jaCJh8sPN4Jnvglu7_qVHK9tDK4m13QKg >>> Wqw1TfhejL4tbxhT2KaR9hdAlSZK8SzRYpUJxz6e1HUj7wQqKB6Ddsk9YvBLj3Z >>> YRpL1aooJCUOv5WRxnxbRdlGR568g1hO0GxFPH7gdfT- >>> wVTrpiLbgcA80j163vTPg6XScic7apv2- >>> uxH6PmiHhniI0S7HOBWggvyDdymhHEyIKjl0VBrj241hwWtsGVrrgux981psezL >>> Uf6xTDpDZxkvwNdxyrHfZN1kgCA_WARX/https%3A%2F%2Fwww.ietf.org%2 >>> Fmailman%2Flistinfo%2Fregext >> _______________________________________________ >> regext mailing list >> regext@ietf.org >> https://www.ietf.org/mailman/listinfo/regext > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
