Hi, I’m bringing this thread back up to look for a path forward with draft-ietf-regext-epp-https. I summarize the state below:
1. draft-ietf-regext-epp-https is defined as a compliant EPP transport, according to Section 2.1 of RFC 5730. 2. EPP is the XML application protocol that currently has a single TCP transport defined in RFC 5734. 3. The goal of draft-ietf-regext-epp-https is to provide a more Cloud-friendly EPP transport, which means that Domain Name Registries (DNRs) can be deployed in the public cloud without having to create custom EPP over TCP (EoT) gateways. Use of the CONNECT HTTP method does not meet this goal. 4. The draft-ietf-regext-epp-https editors are looking for a review from the HTTP Directorate for any HTTP-issues that the EPP experts are not aware of. 5. BCP 56 has been reviewed for draft-ietf-regext-epp-https. The editors of draft-ietf-regext-epp-https don’t see any compliance issues with BCP 56. There is a question of applicability of BCP 56 in defining an HTTP transport for an existing application protocol, such as EPP. 6. The IETF has created an HTTP transport for another application protocol of DNS with DoH in RFC 8484. DoH is also compliant with BCP 56. Any feedback is welcome. Thanks, -- JG [cid87442*[email protected]] James Gould Fellow Engineer [email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Mario Loffredo <[email protected]> Date: Friday, February 6, 2026 at 8:55 AM To: Ben Schwartz <[email protected]>, Pawel Kowalik <[email protected]>, "Gould, James" <[email protected]>, "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: [EXTERNAL] Re: [regext] Re: draft-ietf-regext-epp-https-02 early Httpdir review Resent-From: <[email protected]> Resent-To: <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>, James Gould <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]>, <[email protected]> Resent-Date: Friday, February 6, 2026 at 8:55 AM 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 Ben, please find my inline comments preceded by [ML]. Il 05/02/2026 16:35, Ben Schwartz ha scritto: ________________________________ From: Mario Loffredo <[email protected]><mailto:[email protected]> > We opted for EoH to take advantage from being independent on TCP. I don't understand. Could you clarify? [ML] EPP over TCP, i.e. RFC 5734, maps an EPP session to a TCP connection. Therefore, TCP connections should persist as logn as EPP sessions are alive. However, more importantly, when a TCP connection is lost, the related EPP session ends and no further EPP commands can be issued over that session. In L4 load balancing, TCP connections are kept alive by backend servers. When a backend server crashes or needs to be shut down for maintenance, all ongoing connections are dropped. L7 load balancing is more suitable when maintaing user sessions is essential. Furthemore, L4 load balancing is not always supported on cloud platforms or is complex to implement. Many RSPs that operate multiple domain name registries are planning to migrate their services to a cloud envionment, and EPP over HTTPS supported by a L7 load balancing would be the most suitable solution. > We've explored every solution for managing HTTP sessions on a load-balancing > architecture, from sticky sessions to outsourcing session management to a > Redis cluster. The latter solution offers us maximum flexibility, > scalability, and fault tolerance and implement load balancing very > efficiently. Thanks for sharing. Are you relying on the "Cookie" request header to link HTTP requests with their EPP session? (This seems to be the suggestion in draft-ietf-regext-epp-https-02.) [ML] Yes, exactly. An EPP session is mapped to an HTTP session. Therefore, the EPP session is not tied to a physical connection, but to a logical one. In particular, when the EPP session information is stored outside the pool of backend servers, an EPP command can be processed by any backend server, not necessarily by the one that initiated the HTTP session. As a consequence, no EPP session is lost when a backend server goes down. > My opinion is that WebSocket would not be the right solution, at least not as > efficient as traditional HTTP connections, since WebSocket connections > between client and server are stateful and long-lived via the load balancer. Could you give us some sense of the typical session duration and number of commands per session? [ML] The duration of sessions various, where a best practice is for the client to maintain a pool of established stateful sessions that are kept alive in the background via the EPP Hello Command. Some registrars will establish a session per command, but that introduces undue overhead (e.g., TLS handshake and authentication via the EPP Login Command) in supporting a large set to provisioning commands. Some registries include connection policies for registrars (e.g., bandwidth limit, connection limit) to meet non-discriminatory access that encourages the registrars to maintain a pre-defined set of EPP connections to process provisioning requests from their website. > In this scenario, sticky sessions would be the only option to implement load > balancing for WebSocket, but based on our nearly twenty years of experience > and also widely described in literature, this wouldn't balance the load > efficiently and would require addressing some additional issues, such as > maintaining connection limits, keeping the service up during maintenance > operations, and handling a huge volume of requests. It seems like maintaining session limits is required in either design, and the number of requests is the same either way. However, I appreciate that if each session is bound to a connection, then a session cannot easily outlive its server instance. To determine whether this is acceptable, it would help to understand how long sessions normally last, and how much of a problem it is when a session is closed by the server. [ML] Aside from the benefits of deploying an L7 load balancer on a cloud environment which is one of the reason supporting the implementation of EoH, EPP was designed to be stateful, so any solution that enforces session stability is required. Best, Mario --Ben _______________________________________________ regext mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
