Pawel, I would state that it’s providing an additional option for server and client implementers based on the advantages and disadvantages of each of the transports. EoT has worked well for many years, EoH provides enhanced Cloud capabilities, and EoQ provides some interesting security and performance features that can benefit some registries and registrars.
Thanks, -- JG [cid87442*image001.png@01D960C5.C631DA40] James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: "kowa...@denic.de" <kowa...@denic.de> Date: Tuesday, February 4, 2025 at 8:45 AM To: James Gould <jgo...@verisign.com>, "gal...@elistx.com" <gal...@elistx.com>, "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] Re: [regext] Re: CALL FOR ADOPTION: draft-yao-regext-epp-quic and draft-loffredo-regext-epp-over-http Hi Jim, Got it. Is it a problem to solve or solution looking for a problem? Kind regards, Pawel On 04.02.25 14:38, Gould, James wrote: Pawel, I will mirror what I stated at the IETF 119 session, that there are economies of scale to have both EoH and EoQ progress at the same time. Based on my implementation experience with EoQ, it has security and functional advantages over EoT. Specifically, the encryption is setup ahead of time with the QUIC connection and a set of streams (EoQ connections) can be setup without the overhead of setting up the encryption via a TLS handshake, so a set of EoQ connections can be established quicker. EoQ can provide security and performance enhancements over EoT and is lower level than EoH for those registries that have the need for higher performance. All the transports (EoT, EoH, and EoQ) are pluggable, so they can be chosen based on the needs of the EPP registry and the registrars. The Verisign EPP SDK 1.17.0.2, published at https://www.verisign.com/en_US/channel-resources/domain-registry-products/epp-sdks, has an implementation of the transports if you would like to try them out. Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com<mailto:jgo...@verisign.com> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com><mailto:applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/><http://secure-web.cisco.com/15J-XJf04Kc4I_PLOANKrZipQGhrfa7_7svTD-UYYXocL6mOii51I_HLCVJ-Jtc8AGpyj59xo-xlwYvxiHV8Anxha_fmsdUm7sWa6R8rnI8kKPffXa2YR9Xd-r6VapaaAlR2KLK2Cm9ussrjDVW9wzoZzQDl2OkmR0cSqwBzLbidgkqnIsUgFFr6v0SZWPW0MQxqlzkSMjNiQGl8oREK7XRvj1lLJ-DRrivIFAunLe9cK7FCaDP_akVC_ygTZL3Y6LkaFI9oM0Y_L9ccHdZPaXhqIaVkm3nvdgYhVfqzBGqY/http%3A%2F%2Fverisigninc.com%2F> On 2/4/25, 3:59 AM, "kowa...@denic.de<mailto:kowa...@denic.de> <mailto:kowa...@denic.de><mailto:kowa...@denic.de>" <kowa...@denic.de<mailto:kowa...@denic.de> <mailto:kowa...@denic.de><mailto:kowa...@denic.de>> wrote: A clear +1 for adoption of DoH. For DoQ I share the opinions expressed in the room in IETF 119 session, that benefits from adding this transport are not clear, so I don't think we should spend cycles on this draft until this is better answered. Adding this new transport on a Standard track would mean that EPP will have two standard transports without telling why someone should decide for one instead of the other. Kind Regards, Pawel On 03.02.25 15:05, James Galvin wrote: Continuing our potential adoption of new documents, as previously discussed the next two documents will be taken together. The suggestion is to advance them together, although if these are adopted the working group can choose to advance them separately.
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
