Speaking as co-Chair:
This is a great technical discussion. I’m more inclined to suggest
taking on board both documents expressly because it draws out this
question and we can thoroughly vet it.
Just because we take the documents on board does not mean we have to
progress to publication. If the resolution of the technical discussion
is that we don’t need both specifications then we simply advance the
one we select. The Shepherd Writeup would include a description of the
issue, discussion, and result for the historical record.
Jim
co-Chair REGEXT
On 4 Feb 2025, at 8:52, Gould, James wrote:
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
