> -Original Message-
> From: George Michaelson
> Sent: Wednesday, March 20, 2024 11:00 PM
> To: Hollenbeck, Scott
> Cc: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] EPP Transport Service Discovery
>
> Caution: This email originated from outside the organization. Do not click
>
I very much tend to believing that SVCB is the way to do this. Not to
emebed, not to invent, to use the existing mechanisms to find
transports with flagging to rank server side preferences.
This also serves to bootstrap TLS and so is a "two birds with one
stone" solution.
* its how other
+1
During my 14-year tenure on the registrar side, where we implemented almost
every gTLD and many ccTLDs, I always felt well-informed by registries if they
intended to make substantial changes. While this feature seems nice, I don’t
know if the effort is worth it.
Best,
Tobias
> On 20. Mar
+1
We’ve had experience of adding and removing transports many years ago and it
was done with adequate notice to the registrars.
--
JG
[cid87442*image001.png@01D960C5.C631DA40]
James Gould
Fellow Engineer
jgo...@verisign.com
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Just adding my 2 cents.
It seems that designing and implementing a discovery system seems to be a bit
complicated and will take some time to design and complete. Every registry
will be contacting registrars when a new system is enabled, or at least should
be. I don’t see a huge benefit of
Hi Chairs,
this is to inform you that I just completed the shepherd's writeup of
rir-search.
Best,
Mario
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1,
Scott, et al,
This seems to me an excellent idea, but let me suggest adding a bit more
content.
And before doing so, let me acknowledge that a registry will likely inform
its registrars well in advance of any changes and will likely provide a
test system for registers to use in advance of a
> On 20 Mar 2024, at 08:09, Bill Woodcock wrote:
>
> “Telling people about it” doesn’t get them to upgrade.
Neither would publishing some discovery info (presumably in the DNS).
> If we want to improve things, we actually need to improve things, not just
> talk about it.
I agree. What I
> On Mar 20, 2024, at 08:50, Jim Reid wrote:
>> On 20 Mar 2024, at 07:04, Bill Woodcock wrote:
>> Yes, because the registry can improve over time, and the registrars can
>> update their software over time. If we don’t give updated client-side
>> software a mechanism to discover that the
Hi Scott,
On 20.03.24 05:56, Hollenbeck, Scott wrote:
-Original Message-
From: Francisco Obispo
Sent: Wednesday, March 20, 2024 12:32 AM
To: Hollenbeck, Scott
Cc:regext@ietf.org
Subject: [EXTERNAL] Re: [regext] EPP Transport Service Discovery
This is a neat idea,
Is there a reasoning
> On 20 Mar 2024, at 07:04, Bill Woodcock wrote:
>
> Yes, because the registry can improve over time, and the registrars can
> update their software over time. If we don’t give updated client-side
> software a mechanism to discover that the server now supports improved
> transport, we get
-Original Message-
From: Francisco Obispo
Sent: Wednesday, March 20, 2024 12:32 AM
To: Hollenbeck, Scott
Cc: regext@ietf.org
Subject: [EXTERNAL] Re: [regext] EPP Transport Service Discovery
Caution: This email originated from outside the organization. Do not click links
or open
The. Certificate problem can be dealt with as elsewhere: switch to DANE and
stop accepting CA certs.
-Bill
> On Mar 20, 2024, at 5:33 AM, Francisco Obispo wrote:
>
> This is a neat idea,
>
> Is there a reasoning or use case for such need?
>
> One of the challenges
Yes, because the registry can improve over time, and the registrars can update
their software over time. If we don’t give updated client-side software a
mechanism to discover that the server now supports improved transport, we get
gridlock.
-Bill
> On Mar 20, 2024, at
14 matches
Mail list logo
