Re: [regext] Re: draft-ietf-regext-epp-https-02 early Httpdir review

Thanks, James.  This implementation strategy leaves me puzzled as to the motivating advantage of this design vs. EPP-over-TCP.  In either protocol, it seems that each session is handled entirely by a single backend host, so each session's lifetime is limited by the uptime of that host.

Is the design principally motivated by concerns about TCP connections being interrupted by connectivity issues closer to the client?  Or perhaps by a desire for access to DoS defense capabilities that are available in HTTP gateways but not in TCP load balancers?

--Ben Schwartz
________________________________
From: Gould, James <jgould=40verisign.com@dmarc.ietf.org>
Sent: Thursday, February 19, 2026 2:53 PM
To: Ben Schwartz <bemasc@meta.com>; andy@hxr.us <andy@hxr.us>; mario.loffredo@iit.cnr.it <mario.loffredo@iit.cnr.it>; kowalik@denic.de <kowalik@denic.de>; mnot@mnot.net <mnot@mnot.net>
Cc: ietf-http-wg@w3.org <ietf-http-wg@w3.org>; draft-ietf-regext-epp-https.all@ietf.org <draft-ietf-regext-epp-https.all@ietf.org>; regext@ietf.org <regext@ietf.org>
Subject: Re: [regext] Re: draft-ietf-regext-epp-https-02 early Httpdir review

Ben, The EPP session is terminated, and the client will establish a new EPP session. This happens today with EoT, where the clients will auto-reconnect. EPP is an idempotent, so a client can reconnect and resubmit the request. -- JG James Gould


Ben,



The EPP session is terminated, and the client will establish a new EPP session.  This happens today with EoT, where the clients will auto-reconnect.  EPP is an idempotent, so a client can reconnect and resubmit the request.



--



JG

[cid87442*image001.png@01D960C5.C631DA40]

James Gould
Fellow Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<https://urldefense.com/v3/__http://verisigninc.com/__;!!Bt8RZUm9aw!58QcFLMbpRmn2UyvjuttyfMdLY_f6GEzRcKRlx-FWb7qnH3r8z1Fp6IaRM_xm8iym48XjZQGaFxMwjXotYTu7hm80qo$>



From: Ben Schwartz <bemasc=40meta.com@dmarc.ietf.org>
Date: Thursday, February 19, 2026 at 2:50 PM
To: James Gould <jgould@verisign.com>, "andy@hxr.us" <andy@hxr.us>, "mario.loffredo@iit.cnr.it" <mario.loffredo@iit.cnr.it>, "kowalik@denic.de" <kowalik@denic.de>, James Gould <jgould@verisign.com>, "mnot@mnot.net" <mnot@mnot.net>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "draft-ietf-regext-epp-https.all@ietf.org" <draft-ietf-regext-epp-https.all@ietf.org>, "regext@ietf.org" <regext@ietf.org>
Subject: [EXTERNAL] Re: [regext] Re: draft-ietf-regext-epp-https-02 early Httpdir review



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.

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<https://urldefense.com/v3/__https://secure-web.cisco.com/1Rk5-rXY-lwsUIUsrqMEGRdlHU16lOV6f-hRsK0PA9jLcqykeDOpWiBEruxwlDmN50UzoS1PNpr9vYNe_gFPyaDUryhg2JGJNfKUxE6o1CCDq780uex1YdOj32P6x8SPh2W9sq1REpwQx1HhaNMj0mMzXgBky8UDKFFed-pYRI40LJ8E9GVHt6lSk-X2bVJ-4g0V6b_GJhY9gvMiWvFscfXMZ7WHYx3dR1l8vt9zzVYKkX8KEO_qsRq7nkNUBc4iy_SgHXExrDhAxctdrAyjgdCNW8BiubgPkVmDDUPAPkTM/https*3A*2F*2Fdevelopers.cloudflare.com*2Fload-balancing*2Funderstand-basics*2Fsession-affinity*2F*23cookie__;JSUlJSUlJSU!!Bt8RZUm9aw!58QcFLMbpRmn2UyvjuttyfMdLY_f6GEzRcKRlx-FWb7qnH3r8z1Fp6IaRM_xm8iym48XjZQGaFxMwjXotYTuHl7UJ04$>



________________________________

From: Gould, James <jgould=40verisign.com@dmarc.ietf.org>
Sent: Thursday, February 19, 2026 2:39 PM
To: andy@hxr.us <andy@hxr.us>; mario.loffredo@iit.cnr.it <mario.loffredo@iit.cnr.it>; Ben Schwartz <bemasc@meta.com>; kowalik@denic.de <kowalik@denic.de>; jgould=40verisign.com@dmarc.ietf.org <jgould@verisign.com>; mnot@mnot.net <mnot@mnot.net>
Cc: ietf-http-wg@w3.org <ietf-http-wg@w3.org>; draft-ietf-regext-epp-https.all@ietf.org <draft-ietf-regext-epp-https.all@ietf.org>; regext@ietf.org <regext@ietf.org>
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
jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>

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" <andy@hxr.us <mailto:andy@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.




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