For clarity, are you referring to "sticky HTTP sessions" as identified by 
session cookie, like [1]?

In this implementation style, what happens to active sessions when the assigned 
backend host is decommissioned or restarted?

--Ben Schwartz

[1] 
https://developers.cloudflare.com/load-balancing/understand-basics/session-affinity/#cookie

________________________________
From: Gould, James <[email protected]>
Sent: Thursday, February 19, 2026 2:39 PM
To: [email protected] <[email protected]>; [email protected] 
<[email protected]>; Ben Schwartz <[email protected]>; [email protected] 
<[email protected]>; [email protected] <[email protected]>; 
[email protected] <[email protected]>
Cc: [email protected] <[email protected]>; 
[email protected] 
<[email protected]>; [email protected] <[email protected]>
Subject: Re: [regext] Re: draft-ietf-regext-epp-https-02 early Httpdir review

Andy,

Cloud HTTP gateways do support sticky HTTP sessions, which is what is used by 
draft-ietf-regext-epp-https.  With draft-ietf-regext-epp-https (EoH) there will 
be no need for a registry to build customer EoT gateways.

--

JG



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 
<https://urldefense.com/v3/__http://verisigninc.com/__;!!Bt8RZUm9aw!6I7U3WeXxoJ1-1H9FhV7rSddOKpsUUYE5r5HyVyqFvW_kf7WruW5ag5ZehSILvWRpdh4MLUlIAVy716i6bsgbcKWi2A$
 >




On 2/19/26, 2:17 PM, "Andy Newton" <[email protected] <mailto:[email protected]>> 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.




On 2/19/26 11:32 AM, Gould, James wrote:
> 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.


I am befuddled by the "cloud-friendly" marketing as well. There are currently 
several RSPs who operate EPP using cloud providers, and many cloud providers 
have network load balancers that do TLS termination. From what I can tell, this 
draft doesn't work well with cloud-based web-application firewalls as each EPP 
operation uses the same path (or did I miss something), requiring custom 
parsing of the EPP XML bodies to do any app-layer routing.


Can you point to the specific technical challenge this is referencing?


Mario's message seemed to indicate that the desired connection model was about 
using reverse proxies which can be done on-prem or in a cloud. From that, I 
believe the issue he is solving is the lack of graceful session closure by the 
server in EPP. I am only guessing, but that seems like it could be solved with 
a simple EPP extension.


-andy, as an observer



_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to