Ben, My feedback is embedded below.
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: Ben Schwartz <[email protected]> Date: Wednesday, February 4, 2026 at 4:17 PM To: "Gould, James" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: [EXTERNAL] Re: 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: Wednesday, February 4, 2026 at 4:17 PM 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. ________________________________ From: Gould, James <[email protected]> > EoH uses HTTP GET to the HTTP server to establish the EPP session that > returns the EPP greeting packet. EoH then goes into a command and response > loop and leverages HTTP POST from the client to send the EPP command packet > and to receive the EPP response packet. As I mentioned, this design seems unlikely to work well in common "cloud" CDN models, because the requests that make up one "loop" will likely be load-balanced across several EPP session servers. JG-The HTTP GET establishes the HTTP session, that can be used to route to the appropriate EPP server for the command and response EPP flow. EPP is a stateful application protocol and the EPP session is established upfront to help load balance to the correct EPP server. > The goal with EoH is to enable the 20+ year old EPP application protocol to > ride on HTTP to provide for a more Cloud-friendly option for registries. It would help to have a clearer sense of what "cloud-friendly" means here. In my view, the proposed design is not "cloud-friendly", because it is likely to be broken if deployed in the most natural way using an HTTP gateway. JG-Cloud-friendly means that Cloud HTTP gateways can be leveraged instead of requiring the registry to implement custom EPP gateways that is currently required for EoT. > HTTP has been used as an EPP transport by many EPP registries, and we want to > standardize it in draft-ietf-regext-epp-https. Does this draft document an existing deployed protocol, or is it proposing a new one? If the protocol is already deployed and not subject to significant revision, then the proposed status should be "Informational". JG-No, it’s based on a mix of past deployments and has been re-considered considering HTTP/2 and HTTP/3. If the IETF has change control, then I suspect EPP-over-WebSocket would be an easier way to pass EPP through HTTP cloud infrastructure. JG-That may be the case, but we still believe that EoH can be deployed effectively. --Ben Schwartz
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
