Hi Ben,
please find my comments inline.
Il 19/02/2026 20:49, Ben Schwartz ha scritto:
For clarity, are you referring to "sticky HTTP sessions" as identified
by session cookie, like [1]?
[ML] AFAIU, yes.
In this implementation style, what happens to active sessions when the
assigned backend host is decommissioned or restarted?
[ML] I imagine they'll be abandoned. However, such an HTTP load
balancing implementation already offers advantages over pure TCP load
balancing (as James pointed out), such as TLS termination.
I'd like to emphasize that this is one strategy. Another strategy for
registry operators who have full control over the load balancing
infrastructure is to store session information outside the backend
server pool. In this case, a session remains active even when the
backend server that initiated it is shut down.
Best,
Mario
--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]
<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
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
